From llvm at assumetheposition.nl  Mon Jun  1 04:06:44 2009
From: llvm at assumetheposition.nl (Paul Melis)
Date: Mon, 01 Jun 2009 13:06:44 +0200
Subject: [LLVMdev] CMake build maturity
In-Reply-To: <87fxeqk05c.fsf@telefonica.net>
References: <4A15158A.2010702@laposte.net>
	<4A15CA60.5090108@telenix.org>	<305d6f60905211611w555ac98k76a13a05ba6549b0@mail.gmail.com>	<4A16B53D.7080806@telenix.org>	<31963.75942.qm@web62005.mail.re1.yahoo.com>	<4A16C2E3.1010604@telenix.org>
	<874ovdt4az.fsf@telefonica.net>	<4A1704AC.8050500@assumetheposition.nl>	<87zld4svbr.fsf@telefonica.net>	<4A1D1926.8010405@assumetheposition.nl>
	<87fxeqk05c.fsf@telefonica.net>
Message-ID: <4A23B644.2000500@assumetheposition.nl>

Óscar Fuentes wrote:
> Paul Melis <llvm at assumetheposition.nl> writes:
>
>   
>> It seems that the llvm-config generated when building through CMake does
>> not contain -lpthread on my 32-bit Core2Duo Gentoo Linux system (even
>> though I configured with LLVM_ENABLE_PTHREADS). I get missing symbols
>> during linking of e.g. the JIT tutorial code:
>>     
>
> [snip]
>
> This should be fixed now. Now about this one:
>
>   
>> Adding -lpthread to the compile command manually fixes it, but there
>> seem to be some more discrepancies between the output of llvm-config for
>> a build using ./configure and one using CMake:
>>
>> melis at juggle2:~/c/llvm-svn> ./configure --prefix=/home/melis/llvm
>> --enable-optimized
>> melis at juggle2:~/c/llvm-svn> make install
>> melis at juggle2:~/c/llvm-svn> which llvm-config
>> /home/melis/llvm/bin/llvm-config
>> melis at juggle2:~/c/llvm-svn> llvm-config --cxxflags --ldflags --libs core
>> -I/home/melis/llvm/include  -D_DEBUG  -D_GNU_SOURCE
>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O3 -fomit-frame-pointer
>> -fPIC  -Woverloaded-virtual
>> -L/home/melis/llvm/lib  -lpthread -ldl -lm -lelf
>> -lLLVMCore -lLLVMSupport -lLLVMSystem
>>
>> melis at juggle2:~/c/llvm-svn-build> cmake /home/melis/c/llvm-svn
>> -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/home/melis/llvm-cmake
>> -DLLVM_ENABLE_THREADS=ON
>> melis at juggle2:~/c/llvm-svn-build> make install
>> melis at juggle2:~/c/llvm-svn-build> which llvm-config
>> /home/melis/llvm-cmake/bin/llvm-config
>> melis at juggle2:~/c/llvm-svn-build> llvm-config --cxxflags --ldflags
>> --libs core
>> -I/home/melis/llvm-cmake/include -O3 -DNDEBUG  -D_GNU_SOURCE
>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS
>> -L/home/melis/llvm-cmake/lib 
>> -lLLVMCore -lLLVMSupport -lLLVMSystem
>>
>> I'm actually also surprised about the _DEBUG versus NDEBUG difference...
>>     
>
> I'm surprised too.
>
> Question for those who know: why is _DEBUG and not NDEBUG defined on a
> --enable-optimize'd build?
>   
I guess to keep all the assertions around. I think you need
--disable-assertions to make those go away as well.

Regards.
Paul



From camille at osculator.net  Mon Jun  1 04:25:16 2009
From: camille at osculator.net (Camille Troillard)
Date: Mon, 1 Jun 2009 13:25:16 +0200
Subject: [LLVMdev] Questions about LLVM
Message-ID: <de35c4ed0906010425vcf2952ewfebec17f7287b9d2@mail.gmail.com>

Dear list,
I am learning LLVM and would like to add JIT support to the F-Script
language.  F-Script is a Smalltalk like scripting language that lives in the
Objective-C runtime.  It is written by Philippe Mougin.

The goal is for me to become more familiar with LLVM, and learn about the
conclusions we can draw in terms performance improvements (or degradation
!), possible optimizations, etc.  So far, I have followed with great
interest the Kaleidoscope tutorial, this gave me an initial idea of what
needs to be accomplished.

In F-Script everything is represented as an Objective-C object.
When a block is parsed, a AST representation is built and then interpreted.
 The mechanics of interpretation are rather complicated, and for a start, I
would like to stay way from that.  Thus, I have chosen to JIT only
expressions, but not blocks (yet).

My question are:

1. Do you think it would make sense to use the clang codebase (specifically
Objective-C CodeGen / CGObjCRuntime) in order to generate the code that will
replace F-Script's interpretation?  If that is possible it would enable me
to start progressively porting F-Script to LLVM, instead of reinventing the
wheel and port everything at once.

2. If the previous answer is yes, can you point me to some code
where CGObjCRuntime is used?

3. If the previous answer is no, do you have a suggestion for an alternative
approach?


Thank you in advance for your help!


Best Regards,
Camille
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090601/f14288d6/attachment.html>

From llvm at assumetheposition.nl  Mon Jun  1 04:44:29 2009
From: llvm at assumetheposition.nl (Paul Melis)
Date: Mon, 01 Jun 2009 13:44:29 +0200
Subject: [LLVMdev] CMake build maturity
In-Reply-To: <4A23B644.2000500@assumetheposition.nl>
References: <4A15158A.2010702@laposte.net>	<4A15CA60.5090108@telenix.org>	<305d6f60905211611w555ac98k76a13a05ba6549b0@mail.gmail.com>	<4A16B53D.7080806@telenix.org>	<31963.75942.qm@web62005.mail.re1.yahoo.com>	<4A16C2E3.1010604@telenix.org>	<874ovdt4az.fsf@telefonica.net>	<4A1704AC.8050500@assumetheposition.nl>	<87zld4svbr.fsf@telefonica.net>	<4A1D1926.8010405@assumetheposition.nl>	<87fxeqk05c.fsf@telefonica.net>
	<4A23B644.2000500@assumetheposition.nl>
Message-ID: <4A23BF1D.3000004@assumetheposition.nl>

Paul Melis wrote:
> Óscar Fuentes wrote:
>   
>> Paul Melis <llvm at assumetheposition.nl> writes:
>>
>>   
>>     
>>> It seems that the llvm-config generated when building through CMake does
>>> not contain -lpthread on my 32-bit Core2Duo Gentoo Linux system (even
>>> though I configured with LLVM_ENABLE_PTHREADS). I get missing symbols
>>> during linking of e.g. the JIT tutorial code:
>>>     
>>>       
>> [snip]
>>
>> This should be fixed now. Now about this one:
>>
>>   
>>     
>>> Adding -lpthread to the compile command manually fixes it, but there
>>> seem to be some more discrepancies between the output of llvm-config for
>>> a build using ./configure and one using CMake:
>>>
>>> melis at juggle2:~/c/llvm-svn> ./configure --prefix=/home/melis/llvm
>>> --enable-optimized
>>> melis at juggle2:~/c/llvm-svn> make install
>>> melis at juggle2:~/c/llvm-svn> which llvm-config
>>> /home/melis/llvm/bin/llvm-config
>>> melis at juggle2:~/c/llvm-svn> llvm-config --cxxflags --ldflags --libs core
>>> -I/home/melis/llvm/include  -D_DEBUG  -D_GNU_SOURCE
>>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O3 -fomit-frame-pointer
>>> -fPIC  -Woverloaded-virtual
>>> -L/home/melis/llvm/lib  -lpthread -ldl -lm -lelf
>>> -lLLVMCore -lLLVMSupport -lLLVMSystem
>>>
>>> melis at juggle2:~/c/llvm-svn-build> cmake /home/melis/c/llvm-svn
>>> -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/home/melis/llvm-cmake
>>> -DLLVM_ENABLE_THREADS=ON
>>> melis at juggle2:~/c/llvm-svn-build> make install
>>> melis at juggle2:~/c/llvm-svn-build> which llvm-config
>>> /home/melis/llvm-cmake/bin/llvm-config
>>> melis at juggle2:~/c/llvm-svn-build> llvm-config --cxxflags --ldflags
>>> --libs core
>>> -I/home/melis/llvm-cmake/include -O3 -DNDEBUG  -D_GNU_SOURCE
>>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS
>>> -L/home/melis/llvm-cmake/lib 
>>> -lLLVMCore -lLLVMSupport -lLLVMSystem
>>>
>>> I'm actually also surprised about the _DEBUG versus NDEBUG difference...
>>>     
>>>       
>> I'm surprised too.
>>
>> Question for those who know: why is _DEBUG and not NDEBUG defined on a
>> --enable-optimize'd build?
>>   
>>     
> I guess to keep all the assertions around. I think you need
> --disable-assertions to make those go away as well.
>   
Just checked: yup, there's plenty of assert()'s in the headers, so
-D_DEBUG will keep those alive.

Interestingly, when configuring with --enable-optimized and
--disable-assertions the resulting compilation calls itself a
"Release-Asserts build" while all asserts are thrown away, hmmm :)

Paul



From eli.friedman at gmail.com  Mon Jun  1 04:46:48 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Mon, 1 Jun 2009 04:46:48 -0700
Subject: [LLVMdev] Questions about LLVM
In-Reply-To: <de35c4ed0906010425vcf2952ewfebec17f7287b9d2@mail.gmail.com>
References: <de35c4ed0906010425vcf2952ewfebec17f7287b9d2@mail.gmail.com>
Message-ID: <f5aa3e9b0906010446y29ae8f8cl1ebc4d9e90e37bdf@mail.gmail.com>

On Mon, Jun 1, 2009 at 4:25 AM, Camille Troillard<camille at osculator.net> wrote:
> 1. Do you think it would make sense to use the clang codebase (specifically
> Objective-C CodeGen / CGObjCRuntime) in order to generate the code that will
> replace F-Script's interpretation?  If that is possible it would enable me
> to start progressively porting F-Script to LLVM, instead of reinventing the
> wheel and port everything at once.

It's a possibility, but I'm not sure how much it'll help you; writing
the bits you need from scratch shouldn't be much harder than making
ObjC calls in an interpreter.

> 2. If the previous answer is yes, can you point me to some code
> where CGObjCRuntime is used?

I don't think anyone outside of clang is using it at the moment.

On a side note, it's better to ask this sort of question on cfe-dev.

-Eli



From camille at osculator.net  Mon Jun  1 05:34:20 2009
From: camille at osculator.net (Camille Troillard)
Date: Mon, 1 Jun 2009 14:34:20 +0200
Subject: [LLVMdev] Questions about LLVM
In-Reply-To: <f5aa3e9b0906010446y29ae8f8cl1ebc4d9e90e37bdf@mail.gmail.com>
References: <de35c4ed0906010425vcf2952ewfebec17f7287b9d2@mail.gmail.com>
	<f5aa3e9b0906010446y29ae8f8cl1ebc4d9e90e37bdf@mail.gmail.com>
Message-ID: <de35c4ed0906010534w2cd899den3ca311dabfef80b7@mail.gmail.com>

On Mon, Jun 1, 2009 at 1:46 PM, Eli Friedman <eli.friedman at gmail.com> wrote:

>
> > 1. Do you think it would make sense to use the clang codebase
> (specifically
> > Objective-C CodeGen / CGObjCRuntime) in order to generate the code that
> will
> > replace F-Script's interpretation?  If that is possible it would enable
> me
> > to start progressively porting F-Script to LLVM, instead of reinventing
> the
> > wheel and port everything at once.
>
> It's a possibility, but I'm not sure how much it'll help you; writing
> the bits you need from scratch shouldn't be much harder than making
> ObjC calls in an interpreter.


Alright, I can try this way.
Could you please elaborate on "the bits" I would have to write?
Does it mean implementing calls to the objc runtime?
I believe that would not be that difficult.


Cam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090601/b3135788/attachment.html>

From fvbommel at wxs.nl  Mon Jun  1 06:29:56 2009
From: fvbommel at wxs.nl (Frits van Bommel)
Date: Mon, 01 Jun 2009 15:29:56 +0200
Subject: [LLVMdev] CMake build maturity
In-Reply-To: <4A23BF1D.3000004@assumetheposition.nl>
References: <4A15158A.2010702@laposte.net>	<4A15CA60.5090108@telenix.org>	<305d6f60905211611w555ac98k76a13a05ba6549b0@mail.gmail.com>	<4A16B53D.7080806@telenix.org>	<31963.75942.qm@web62005.mail.re1.yahoo.com>	<4A16C2E3.1010604@telenix.org>	<874ovdt4az.fsf@telefonica.net>	<4A1704AC.8050500@assumetheposition.nl>	<87zld4svbr.fsf@telefonica.net>	<4A1D1926.8010405@assumetheposition.nl>	<87fxeqk05c.fsf@telefonica.net>	<4A23B644.2000500@assumetheposition.nl>
	<4A23BF1D.3000004@assumetheposition.nl>
Message-ID: <4A23D7D4.2080108@wxs.nl>

Paul Melis wrote:
> Just checked: yup, there's plenty of assert()'s in the headers, so
> -D_DEBUG will keep those alive.
> 
> Interestingly, when configuring with --enable-optimized and
> --disable-assertions the resulting compilation calls itself a
> "Release-Asserts build" while all asserts are thrown away, hmmm :)

Yeah, that's "Release-Asserts" as in "Release minus asserts".

This has caused confusion before...


From aaronngray.lists at googlemail.com  Mon Jun  1 09:12:07 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Mon, 1 Jun 2009 17:12:07 +0100
Subject: [LLVMdev] MachO writer test cases
Message-ID: <0A6EFE1F7943443C9EC8B8B9D2F31A71@HPLAPTOP>

Is anyone using the MachO Writer ?

If so do you have any test cases as I am moving it over to use the prototype direct object emission code and I need test cases to verify it working correctly.

Many thanks in advance,

Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090601/f3fd883d/attachment.html>

From devang.patel at gmail.com  Mon Jun  1 10:19:23 2009
From: devang.patel at gmail.com (Devang Patel)
Date: Mon, 1 Jun 2009 10:19:23 -0700
Subject: [LLVMdev] Wondering how best to run inlining on a single
	function.
In-Reply-To: <bb55930e0905261515o5c62dlcd4d773bb64ada14@mail.gmail.com>
References: <bb55930e0905261515o5c62dlcd4d773bb64ada14@mail.gmail.com>
Message-ID: <352a1fb20906011019p6a1a35e1o8a0e34b15aa9f4f3@mail.gmail.com>

Hi Jeffrey,

On Tue, May 26, 2009 at 3:15 PM, Jeffrey Yasskin <jyasskin at google.com> wrote:
> In Unladen Swallow we (intend to) compile each function as we
> determine it's hot. To "compile" a function means to translate it from
> CPython bytecode to LLVM IR, optimize the IR using a
> FunctionPassManager, and JIT the IR to machine code. We'd like to
> include inlining among our optimizations. Currently the Inliner is a
> CallGraphSCCPass, which can only be run by the (Module)PassManager and
> which will try to inline calls into every function in the module,
> including functions we've already optimized. This seems like it will
> waste time.
>
> I think that, because we optimize every Python function as we generate
> it, it makes sense to write a SingleFunctionInliner (is there a better
> name?) that acts as a FunctionPass and add that to our normal
> FunctionPassManager. Can you guys see anything that will go wrong if I
> do that? Is there a better way, or an option that doesn't involve
> writing new code?

Try BasicInliner  from lib/Transforms/Utils/BasicInliner.cpp
-
Devang


From natebegeman at me.com  Mon Jun  1 10:40:17 2009
From: natebegeman at me.com (Nate Begeman)
Date: Mon, 01 Jun 2009 10:40:17 -0700
Subject: [LLVMdev] MachO writer test cases
In-Reply-To: <0A6EFE1F7943443C9EC8B8B9D2F31A71@HPLAPTOP>
References: <0A6EFE1F7943443C9EC8B8B9D2F31A71@HPLAPTOP>
Message-ID: <77A779F8-048A-4B9C-B708-78DF37C104ED@me.com>

I doubt anyone is using it, as it is not complete.

On Jun 1, 2009, at 9:12 AM, Aaron Gray wrote:

> Is anyone using the MachO Writer ?
>
> If so do you have any test cases as I am moving it over to use the  
> prototype direct object emission code and I need test cases to  
> verify it working correctly.
>
> Many thanks in advance,
>
> Aaron
>
> _______________________________________________
> 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.llvm.org/pipermail/llvm-dev/attachments/20090601/fa803020/attachment.html>

From dalej at apple.com  Mon Jun  1 10:48:31 2009
From: dalej at apple.com (Dale Johannesen)
Date: Mon, 1 Jun 2009 10:48:31 -0700
Subject: [LLVMdev] debug info for global variables when optimising
In-Reply-To: <ee2e06e90905290624r743a03bdwa193bd64233ed23@mail.gmail.com>
References: <ee2e06e90905290624r743a03bdwa193bd64233ed23@mail.gmail.com>
Message-ID: <C7C054D5-842B-4B57-95C4-98DA9B5AB968@apple.com>


On May 29, 2009, at 6:24 AMPDT, Jay Foad wrote:

> I see that llvm-gcc now has some support for generating debug info
> when optimising - thanks!
>
> However, it still doesn't generate debug info for global variables
> when optimising. Is there any reason for this? With the attached
> patch, the whole test suite passes for me with TEST=ipodbgopt.

The reason is given in the comment your patch deletes.  Having debug  
info affect the codegen is pretty bad, because you get situations  
where a bug goes away when you turn on debug info,  and you can't  
debug it.

TEST=ipodbgopt currently runs through -strip-debug-declare  
immediately, which would hide such cases.  Try it with that flag  
removed and I bet you'll see some failures.

> Thanks,
> Jay.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.globaldebug
Type: application/octet-stream
Size: 609 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090601/1932907d/attachment.obj>
-------------- next part --------------
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From aaronngray.lists at googlemail.com  Mon Jun  1 12:18:39 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Mon, 1 Jun 2009 20:18:39 +0100
Subject: [LLVMdev] MachO writer test cases
References: <0A6EFE1F7943443C9EC8B8B9D2F31A71@HPLAPTOP>
	<77A779F8-048A-4B9C-B708-78DF37C104ED@me.com>
Message-ID: <2658EA9154194EF9A82CF6E330526E70@HPLAPTOP>

Nate,

Right, okay. I was also planning on looking at what the assembly output generates and "emulating" its output.

So I should be able to use the 'test/CodeGen/PowerPC' tests once I have augmented the MachO Writer PowerPC output.

Does this seem like the right and sensible approach ?

Aaron


----- Original Message ----- 
  From: Nate Begeman 
  To: LLVM Developers Mailing List 
  Sent: Monday, June 01, 2009 6:40 PM
  Subject: Re: [LLVMdev] MachO writer test cases


  I doubt anyone is using it, as it is not complete.


  On Jun 1, 2009, at 9:12 AM, Aaron Gray wrote:


    Is anyone using the MachO Writer ?

    If so do you have any test cases as I am moving it over to use the prototype direct object emission code and I need test cases to verify it working correctly.

    Many thanks in advance,

    Aaron

    _______________________________________________
    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.llvm.org/pipermail/llvm-dev/attachments/20090601/3c35e05a/attachment.html>

From vargaz at gmail.com  Mon Jun  1 13:57:11 2009
From: vargaz at gmail.com (Zoltan Varga)
Date: Mon, 1 Jun 2009 22:57:11 +0200
Subject: [LLVMdev] [PATH] Fix support for .umul.with.overflow on x86 + fix c
	binding
Message-ID: <295e750a0906011357o3711ac89qa7bdb505889cf2ca@mail.gmail.com>

Hi,

  The first patch fixes the implementation of umul.with.overflow on x86
which was throwing a 'Cannot yet select' error.
  The second patch fixes the definition of LLVMTypeKind in the C binding by
syncing it with the c++ counterpart.

Please review and commit if it looks ok.

             thanks

                Zoltan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090601/149fa968/attachment.html>

From vargaz at gmail.com  Mon Jun  1 14:44:40 2009
From: vargaz at gmail.com (Zoltan Varga)
Date: Mon, 1 Jun 2009 23:44:40 +0200
Subject: [LLVMdev] [PATH] Fix support for .umul.with.overflow on x86 +
	fix c binding
In-Reply-To: <295e750a0906011357o3711ac89qa7bdb505889cf2ca@mail.gmail.com>
References: <295e750a0906011357o3711ac89qa7bdb505889cf2ca@mail.gmail.com>
Message-ID: <295e750a0906011444n325e649bm5bb25dab52382e1e@mail.gmail.com>

Hi,

  Forgot the patch...

               Zoltan

On Mon, Jun 1, 2009 at 10:57 PM, Zoltan Varga <vargaz at gmail.com> wrote:

> Hi,
>
>   The first patch fixes the implementation of umul.with.overflow on x86
> which was throwing a 'Cannot yet select' error.
>   The second patch fixes the definition of LLVMTypeKind in the C binding by
> syncing it with the c++ counterpart.
>
> Please review and commit if it looks ok.
>
>              thanks
>
>                 Zoltan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090601/98d2f515/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: umul.diff
Type: text/x-patch
Size: 8009 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090601/98d2f515/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-c.diff
Type: text/x-patch
Size: 607 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090601/98d2f515/attachment-0001.bin>

From aaronngray.lists at googlemail.com  Mon Jun  1 14:45:16 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Mon, 1 Jun 2009 22:45:16 +0100
Subject: [LLVMdev] [PATH] Fix support for .umul.with.overflow on x86 +
	fix cbinding
References: <295e750a0906011357o3711ac89qa7bdb505889cf2ca@mail.gmail.com>
Message-ID: <44ADBD59F73A4F058F7A3FFB23EF3BA9@HPLAPTOP>

Zoltan,

No patches are attached anything over 100K or so removed. Best to send to send any patches to the commits list.

Aaron

  ----- Original Message ----- 
  From: Zoltan Varga 
  To: LLVM Developers Mailing List 
  Sent: Monday, June 01, 2009 9:57 PM
  Subject: [LLVMdev] [PATH] Fix support for .umul.with.overflow on x86 + fix cbinding


  Hi,

    The first patch fixes the implementation of umul.with.overflow on x86 which was throwing a 'Cannot yet select' error.
    The second patch fixes the definition of LLVMTypeKind in the C binding by syncing it with the c++ counterpart.

  Please review and commit if it looks ok.

               thanks

                  Zoltan



------------------------------------------------------------------------------


  _______________________________________________
  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.llvm.org/pipermail/llvm-dev/attachments/20090601/b4082189/attachment.html>

From devang.patel at gmail.com  Mon Jun  1 15:38:41 2009
From: devang.patel at gmail.com (Devang Patel)
Date: Mon, 1 Jun 2009 15:38:41 -0700
Subject: [LLVMdev] Origin of DEBUG and EH label values
In-Reply-To: <16A62A187FD14180AD1A537F21E5311A@HPLAPTOP>
References: <16A62A187FD14180AD1A537F21E5311A@HPLAPTOP>
Message-ID: <352a1fb20906011538r7a57ec1lf1e8db3be8344dd7@mail.gmail.com>

On Sun, May 3, 2009 at 3:41 PM, Aaron Gray
<aaronngray.lists at googlemail.com> wrote:
> Where do DEBUG and EH label values originate from ?
>
> Where's their allocator ?
>
> I am looking at some code in X86CodeEmitter.cpp line 574, where a labels
> value is extraced from an operand.
>
> But dont know where to look in the frontend or middle end to find the
> LabelID allocator.

See how Intrinsic::dbg_* are lowered by SelectionDAGBuild.cpp and FastISel.cpp

-
Devang



From dag at cray.com  Mon Jun  1 15:53:17 2009
From: dag at cray.com (David Greene)
Date: Mon, 1 Jun 2009 17:53:17 -0500
Subject: [LLVMdev] RFC: AVX Intrinsics
Message-ID: <200906011753.17532.dag@cray.com>

Where would people like me to put AVX intrinsic definitions?

I could put them in the current IntrinsicsX86.td or put them
in a new file.  We've called it IntrinsicsX86AVX.td.  We put ours
in a separate file to avoid upstream conflicts but now that we're
getting ready to merge our stuff up we'd like the LLVM community's
opinion on where it should go.

Thanks.

                                -Dave


From eli.friedman at gmail.com  Mon Jun  1 16:14:46 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Mon, 1 Jun 2009 16:14:46 -0700
Subject: [LLVMdev] [PATH] Fix support for .umul.with.overflow on x86 +
	fix c binding
In-Reply-To: <295e750a0906011444n325e649bm5bb25dab52382e1e@mail.gmail.com>
References: <295e750a0906011357o3711ac89qa7bdb505889cf2ca@mail.gmail.com>
	<295e750a0906011444n325e649bm5bb25dab52382e1e@mail.gmail.com>
Message-ID: <f5aa3e9b0906011614u753feffcr8cf248d9ba2d4e93@mail.gmail.com>

On Mon, Jun 1, 2009 at 2:44 PM, Zoltan Varga<vargaz at gmail.com> wrote:
> Hi,
>
>   Forgot the patch...

The patch for umul is simply wrong; try reading the Intel x86
instruction manual.

-Eli



From clattner at apple.com  Mon Jun  1 22:06:28 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 1 Jun 2009 22:06:28 -0700
Subject: [LLVMdev] RFC: AVX Intrinsics
In-Reply-To: <200906011753.17532.dag@cray.com>
References: <200906011753.17532.dag@cray.com>
Message-ID: <239666F1-7E43-4B37-976B-F4CFF3BDFC51@apple.com>


On Jun 1, 2009, at 3:53 PM, David Greene wrote:

> Where would people like me to put AVX intrinsic definitions?
>
> I could put them in the current IntrinsicsX86.td or put them
> in a new file.  We've called it IntrinsicsX86AVX.td.  We put ours
> in a separate file to avoid upstream conflicts but now that we're
> getting ready to merge our stuff up we'd like the LLVM community's
> opinion on where it should go.

IntrinsicsX86AVX.td seems reasonable to me.

-Chris


From jrk at csail.mit.edu  Mon Jun  1 23:17:25 2009
From: jrk at csail.mit.edu (Jonathan Ragan-Kelley)
Date: Mon, 1 Jun 2009 23:17:25 -0700 (PDT)
Subject: [LLVMdev] RFC: Atomics.h
In-Reply-To: <B30EFF3F-2A50-458D-977B-452BE7D0C288@mac.com>
References: <6A0323F4-704E-43F5-9176-DF8F25EA0B65@mac.com> 
	<295e750a0905161500g788765edr2da536519c4b7873@mail.gmail.com> 
	<E14861AF-99D7-43F5-BEF8-81FD30FEA2C6@mac.com>
	<BCAD37BF-1B87-4A7D-AFBE-293B1F8A07E3@apple.com> 
	<6BF939BD-723F-40B9-8E53-BBE414631991@mac.com>
	<da5dd333-4a61-440b-a037-6612f2b4e437@3g2000yqk.googlegroups.com>
	<B30EFF3F-2A50-458D-977B-452BE7D0C288@mac.com>
Message-ID: <a16b1b15-5238-4416-b712-0ac0ea909c5a@h18g2000yqj.googlegroups.com>

Yes, indeed.

On May 28, 10:41 pm, Owen Anderson <resis... at mac.com> wrote:
>
> Wait, it defines MemoryFence() AND MemoryBarrier()??
>
> Sheesh, they had to take all the reasonable names.  :-/



From eric at brouhaha.com  Tue Jun  2 00:16:13 2009
From: eric at brouhaha.com (Eric Smith)
Date: Tue, 02 Jun 2009 00:16:13 -0700
Subject: [LLVMdev] LLVM-gcc for Ada
Message-ID: <4A24D1BD.2070900@brouhaha.com>

I'm having problems building llvm-gcc for Ada, which may or may not be 
similar to the trouble Andre was having recently.  I'm trying to build 
it on Fedora 10 (32-bit), using the instructions on the web site.  The 
make terminates with a gnatbind error:

gcc -c -g -O2      -gnatpg -gnata -I- -I. -Iada 
-I../../llvm-gcc-4.2/gcc/ada ../../llvm-gcc-4.2/gcc/ada/gnat1drv.adb -o 
ada/gnat1drv.o
gnatbind -C -I- -I. -Iada -I../../llvm-gcc-4.2/gcc/ada -o ada/b_gnat1.c 
-n ada/gnat1drv.ali
error: "s-imenne.adb" must be compiled
error: ("/usr/lib/gcc/i386-redhat-linux/4.3.2/adalib/s-imenne.ali" is 
obsolete and read-only)
error: "s-imenne.adb" and "gnat1drv.adb" compiled with different 
exception handling mechanisms
make[2]: *** [ada/b_gnat1.c] Error 5
make[2]: Leaving directory `/home/eric/llvm/llvm-gcc-4.2-objects/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/home/eric/llvm/llvm-gcc-4.2-objects'
make: *** [all] Error 2

Any ideas how I can fix that?  Is this happening due to using the GCC 
and Gnat 4.3 to build it?  I thought I could try installing an earlier 
version of Fedora that has GCC 4.2, but it looks like they jumped from 
4.1 to 4.3.

If there's not a simple fix, is there a Linux distro on which llvm-gcc 
with Ada is known to build "out of the box"?

Thanks!
Eric



From eric at brouhaha.com  Tue Jun  2 00:36:15 2009
From: eric at brouhaha.com (Eric Smith)
Date: Tue, 02 Jun 2009 00:36:15 -0700
Subject: [LLVMdev] Request to Bitter Melon regarding the LLVM demo page
Message-ID: <4A24D66F.50705@brouhaha.com>

Hi Bitter Melon!

If it's not too much trouble, could you add a check box to the LLVM demo 
page to pass the -fnested-functions option to llvm-gcc?  I'm interested 
in studying how nested functions are implemented, but haven't yet been 
able to get llvm-gcc built on my own system.

Thanks!
Eric



From resistor at mac.com  Tue Jun  2 01:41:42 2009
From: resistor at mac.com (Owen Anderson)
Date: Tue, 02 Jun 2009 01:41:42 -0700
Subject: [LLVMdev] RFC: Atomics.h
In-Reply-To: <a16b1b15-5238-4416-b712-0ac0ea909c5a@h18g2000yqj.googlegroups.com>
References: <6A0323F4-704E-43F5-9176-DF8F25EA0B65@mac.com>
	<295e750a0905161500g788765edr2da536519c4b7873@mail.gmail.com>
	<E14861AF-99D7-43F5-BEF8-81FD30FEA2C6@mac.com>
	<BCAD37BF-1B87-4A7D-AFBE-293B1F8A07E3@apple.com>
	<6BF939BD-723F-40B9-8E53-BBE414631991@mac.com>
	<da5dd333-4a61-440b-a037-6612f2b4e437@3g2000yqk.googlegroups.com>
	<B30EFF3F-2A50-458D-977B-452BE7D0C288@mac.com>
	<a16b1b15-5238-4416-b712-0ac0ea909c5a@h18g2000yqj.googlegroups.com>
Message-ID: <56BE3801-56E1-46C3-8B87-C56D74BD67A2@mac.com>

Is this actually the case?  I can't find it documented anywhere on  
MSDN or the rest of the internet.

--Owen

On Jun 1, 2009, at 11:17 PM, Jonathan Ragan-Kelley wrote:

> Yes, indeed.
>
> On May 28, 10:41 pm, Owen Anderson <resis... at mac.com> wrote:
>>
>> Wait, it defines MemoryFence() AND MemoryBarrier()??
>>
>> Sheesh, they had to take all the reasonable names.  :-/
>
> _______________________________________________
> 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: 2620 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090602/3781e7c1/attachment.bin>

From baldrick at free.fr  Tue Jun  2 01:54:43 2009
From: baldrick at free.fr (Duncan Sands)
Date: Tue, 02 Jun 2009 10:54:43 +0200
Subject: [LLVMdev] LLVM-gcc for Ada
In-Reply-To: <4A24D1BD.2070900@brouhaha.com>
References: <4A24D1BD.2070900@brouhaha.com>
Message-ID: <4A24E8D3.10105@free.fr>

Hi Eric,

> I'm having problems building llvm-gcc for Ada, which may or may not be 
> similar to the trouble Andre was having recently.  I'm trying to build 
> it on Fedora 10 (32-bit), using the instructions on the web site.  The 
> make terminates with a gnatbind error:
> 
> gcc -c -g -O2      -gnatpg -gnata -I- -I. -Iada 
> -I../../llvm-gcc-4.2/gcc/ada ../../llvm-gcc-4.2/gcc/ada/gnat1drv.adb -o 
> ada/gnat1drv.o
> gnatbind -C -I- -I. -Iada -I../../llvm-gcc-4.2/gcc/ada -o ada/b_gnat1.c 
> -n ada/gnat1drv.ali
> error: "s-imenne.adb" must be compiled
> error: ("/usr/lib/gcc/i386-redhat-linux/4.3.2/adalib/s-imenne.ali" is 
> obsolete and read-only)
> error: "s-imenne.adb" and "gnat1drv.adb" compiled with different 
> exception handling mechanisms
> make[2]: *** [ada/b_gnat1.c] Error 5
> make[2]: Leaving directory `/home/eric/llvm/llvm-gcc-4.2-objects/gcc'
> make[1]: *** [all-gcc] Error 2
> make[1]: Leaving directory `/home/eric/llvm/llvm-gcc-4.2-objects'
> make: *** [all] Error 2
> 
> Any ideas how I can fix that?  Is this happening due to using the GCC 
> and Gnat 4.3 to build it?

yes, that's exactly the problem.

> I thought I could try installing an earlier 
> version of Fedora that has GCC 4.2, but it looks like they jumped from 
> 4.1 to 4.3.
> 
> If there's not a simple fix, is there a Linux distro on which llvm-gcc 
> with Ada is known to build "out of the box"?

Why don't you install GNAT GPL 2007 (free download, easy to do) and
compile it using that?

Ciao,

Duncan.


From baldrick at free.fr  Tue Jun  2 02:20:41 2009
From: baldrick at free.fr (Duncan Sands)
Date: Tue, 02 Jun 2009 11:20:41 +0200
Subject: [LLVMdev] Request to Bitter Melon regarding the LLVM demo page
In-Reply-To: <4A24D66F.50705@brouhaha.com>
References: <4A24D66F.50705@brouhaha.com>
Message-ID: <4A24EEE9.5060400@free.fr>

Hi Eric,

> If it's not too much trouble, could you add a check box to the LLVM demo 
> page to pass the -fnested-functions option to llvm-gcc?  I'm interested 
> in studying how nested functions are implemented, but haven't yet been 
> able to get llvm-gcc built on my own system.

I turned it on unconditionally.  Meow!

Bitter Melon.


From jay.foad at gmail.com  Tue Jun  2 02:29:59 2009
From: jay.foad at gmail.com (Jay Foad)
Date: Tue, 2 Jun 2009 10:29:59 +0100
Subject: [LLVMdev] problem with TCLSH when reconfiguring LLVM (was Re: make
	TEST=ipodbgopt in sqlite3: problem with TCLSH)
Message-ID: <ee2e06e90906020229v12d52cc0v13898f79f9aa7796@mail.gmail.com>

>> Doesn't the toplevel configure set TCLSH in Makefile.config?

There seems to be a problem with reconfiguring LLVM when you use a
config.cache file. In an empty directory I get:

$ ~/svn/llvm-project/llvm/trunk/configure --cache-file=config.cache
[... lots of stuff ...]
$ grep -i tclsh Makefile.config
TCLSH      := /usr/bin/tclsh8.4
$ ~/svn/llvm-project/llvm/trunk/configure --cache-file=config.cache
[... lots of stuff ...]
$ grep -i tclsh Makefile.config
TCLSH      :=

So the second time I configure, something in config.cache is
scuppering configure's attempt to find tclsh. This seems bad. Can
anyone who know about autoconf explain this? My config.cache contains
these lines:

ac_cv_path_TCLSH=${ac_cv_path_TCLSH=/usr/bin/tclsh8.4}
ac_cv_path_tclsh=${ac_cv_path_tclsh=/usr/bin/tclsh8.4}

Thanks,
Jay.


From eli.friedman at gmail.com  Tue Jun  2 02:57:17 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Tue, 2 Jun 2009 02:57:17 -0700
Subject: [LLVMdev] llvm.eh.unwind.init : missing documentation/incorrect
	implementation?
Message-ID: <f5aa3e9b0906020257s3c686766mc9236ca146ba04fc@mail.gmail.com>

Per subject; I went to look for a description at
http://llvm.org/docs/ExceptionHandling.html , but it wasn't there.

Also, apparently, __builtin_unwind_init is supposed to force
callee-saved registers to be spilled, but llvm.eh.unwind.init doesn't
do that.  This matters because Boehm GC expects the intrinsic to do
that.

-Eli


From Viktar.Zviarovich at brunel.ac.uk  Tue Jun  2 05:19:22 2009
From: Viktar.Zviarovich at brunel.ac.uk (Viktar Zviarovich)
Date: Tue, 2 Jun 2009 13:19:22 +0100
Subject: [LLVMdev] Request to Bitter Melon regarding the LLVM demo page
In-Reply-To: <4A24EEE9.5060400@free.fr>
References: <4A24D66F.50705@brouhaha.com> <4A24EEE9.5060400@free.fr>
Message-ID: <65BE579095BE0C489DB2EC8C7F85E83D6A9C06@UXEXMBU115.academic.windsor>

Hi,

This results in the following warning when using C++ as a source
language:

cc1plus: warning: command line option "-fnested-functions" is valid for
C/ObjC but not for C++

Best regards,
Victor

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
On Behalf Of Duncan Sands
Sent: 02 June 2009 10:21
To: LLVM Developers Mailing List
Subject: Re: [LLVMdev] Request to Bitter Melon regarding the LLVM demo
page

Hi Eric,

> If it's not too much trouble, could you add a check box to the LLVM
demo 
> page to pass the -fnested-functions option to llvm-gcc?  I'm
interested 
> in studying how nested functions are implemented, but haven't yet been

> able to get llvm-gcc built on my own system.

I turned it on unconditionally.  Meow!

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



From andrelct at dcc.ufmg.br  Tue Jun  2 05:38:47 2009
From: andrelct at dcc.ufmg.br (Andre Tavares)
Date: Tue, 02 Jun 2009 09:38:47 -0300
Subject: [LLVMdev] LLVM-gcc for Ada
In-Reply-To: <4A24E8D3.10105@free.fr>
References: <4A24D1BD.2070900@brouhaha.com> <4A24E8D3.10105@free.fr>
Message-ID: <4A251D57.9070602@dcc.ufmg.br>

Duncan Sands wrote:
> Hi Eric,
>
>   
>> I'm having problems building llvm-gcc for Ada, which may or may not be 
>> similar to the trouble Andre was having recently.  I'm trying to build 
>> it on Fedora 10 (32-bit), using the instructions on the web site.  The 
>> make terminates with a gnatbind error:
>>
>> gcc -c -g -O2      -gnatpg -gnata -I- -I. -Iada 
>> -I../../llvm-gcc-4.2/gcc/ada ../../llvm-gcc-4.2/gcc/ada/gnat1drv.adb -o 
>> ada/gnat1drv.o
>> gnatbind -C -I- -I. -Iada -I../../llvm-gcc-4.2/gcc/ada -o ada/b_gnat1.c 
>> -n ada/gnat1drv.ali
>> error: "s-imenne.adb" must be compiled
>> error: ("/usr/lib/gcc/i386-redhat-linux/4.3.2/adalib/s-imenne.ali" is 
>> obsolete and read-only)
>> error: "s-imenne.adb" and "gnat1drv.adb" compiled with different 
>> exception handling mechanisms
>> make[2]: *** [ada/b_gnat1.c] Error 5
>> make[2]: Leaving directory `/home/eric/llvm/llvm-gcc-4.2-objects/gcc'
>> make[1]: *** [all-gcc] Error 2
>> make[1]: Leaving directory `/home/eric/llvm/llvm-gcc-4.2-objects'
>> make: *** [all] Error 2
>>
>> Any ideas how I can fix that?  Is this happening due to using the GCC 
>> and Gnat 4.3 to build it?
>>     
>
> yes, that's exactly the problem.
>
>   
>> I thought I could try installing an earlier 
>> version of Fedora that has GCC 4.2, but it looks like they jumped from 
>> 4.1 to 4.3.
>>
>> If there's not a simple fix, is there a Linux distro on which llvm-gcc 
>> with Ada is known to build "out of the box"?
>>     
>
> Why don't you install GNAT GPL 2007 (free download, easy to do) and
> compile it using that?
>
> Ciao,
>
> Duncan.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>   
Eric,

That is the same problem I had.

I created a little guide in case someone gets the same trouble as mine. 
So here you are the link 
http://homepages.dcc.ufmg.br/~andrelct/blog/howto/install_llvm-gcc_with_ada_support 




-- 
Andre Tavares
Master Student in Computer Science - UFMG - Brasil
http://dcc.ufmg.br/~andrelct



From varonrotem at gmail.com  Tue Jun  2 05:54:45 2009
From: varonrotem at gmail.com (Rotem Varon)
Date: Tue, 2 Jun 2009 15:54:45 +0300
Subject: [LLVMdev] LiveValues Pass
Message-ID: <4f5edbea0906020554h6f8d6fbfp3ea5d2e74b8077@mail.gmail.com>

Hi,

I need the Instructions live out, so i will be able to run my pass.
One option that i already discussed is to compute it myself.
Second option, use the LiveValues Pass(include/llvm/Analysis/LiveValues).

This questions are on the LiveValues pass:
Do i need to set the "LiveValues" pass in the PassManager as a prerequisite?
if so how do i get the results ?How do i get/use the results of LiveValuse
pass in my pass?
Is there documentation in the LLVM site (beside of the comments on the
file)?
Can i simply use its public function ?

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090602/66939447/attachment.html>

From ihusar at fit.vutbr.cz  Tue Jun  2 06:15:34 2009
From: ihusar at fit.vutbr.cz (ihusar)
Date: Tue, 02 Jun 2009 15:15:34 +0200
Subject: [LLVMdev] LLVM frontend supporting arbitrary bit-width integral
	datatypes
Message-ID: <op.uuwe38tn0lgsd9@localhost.localdomain>

Hello gyus,

I am working on a project, where we are trying to create a development environment 
for new ASIP processor design. Part of this project is a compiler generator, 
where we would like to generate C compiler from some instruction description. 

To keep it short, let's say, that in each instruction's semantics
is described by some C code. What I would like to do is to compile this code with LLVM, 
let it optimize it and then extract instruction selection rules for each instruction (either from LLVM IR
or from created code selection DAG).
Then, I will use these selection rules and some additional information about registers etc. to generate 
LLVM compiler backend for the designed ASIP.

First, I would like to ask, whether you heard about some proects, where they are also trying to generate LLVM backends.
(any related information would be useful)

Second, in the code, that describes instruction's semantics, I need to use some special datatypes 
like 5-bit wide unsigned integer and similar. I heard about some Embedded C extension for the CGG frontend, 
but I have not found anything about it yet. Or, does the CLang support such datatypes?

Have a nice day and thanks in advance
  Adam


From baldrick at free.fr  Tue Jun  2 08:09:54 2009
From: baldrick at free.fr (Duncan Sands)
Date: Tue, 02 Jun 2009 17:09:54 +0200
Subject: [LLVMdev] Request to Bitter Melon regarding the LLVM demo page
In-Reply-To: <65BE579095BE0C489DB2EC8C7F85E83D6A9C06@UXEXMBU115.academic.windsor>
References: <4A24D66F.50705@brouhaha.com> <4A24EEE9.5060400@free.fr>
	<65BE579095BE0C489DB2EC8C7F85E83D6A9C06@UXEXMBU115.academic.windsor>
Message-ID: <4A2540C2.3080001@free.fr>

Hi Victor,

> This results in the following warning when using C++ as a source
> language:
> 
> cc1plus: warning: command line option "-fnested-functions" is valid for
> C/ObjC but not for C++

thanks for pointing this out.  I've reverted the change for the moment
while waiting for a better idea.

Ciao,

Duncan.


From ojomojo at gmail.com  Tue Jun  2 08:47:21 2009
From: ojomojo at gmail.com (John Mosby)
Date: Tue, 2 Jun 2009 09:47:21 -0600
Subject: [LLVMdev] LLVM frontend supporting arbitrary bit-width integral
	datatypes
In-Reply-To: <op.uuwe38tn0lgsd9@localhost.localdomain>
References: <op.uuwe38tn0lgsd9@localhost.localdomain>
Message-ID: <645d868c0906020847n3dbbec84p10a42364c2e191f9@mail.gmail.com>

Take a look at http://tce.cs.tut.fi
This is a current LLVM project: http://llvm.org/ProjectsWithLLVM/#tta-tce

What they are doing might apply to your problem:

TCE generates new LLVM-based code generators "on the fly" for the designed
TTA processors and loads them in to the compiler backend as runtime
libraries to avoid per-target recompilation of larger parts of the compiler
chain.

Cheers,
John

On Tue, Jun 2, 2009 at 7:15 AM, ihusar <ihusar at fit.vutbr.cz> wrote:

> Hello gyus,
>
>  First, I would like to ask, whether you heard about some proects, where
> they are also trying to generate LLVM backends.
> (any related information would be useful)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090602/38180123/attachment.html>

From natebegeman at me.com  Tue Jun  2 09:59:15 2009
From: natebegeman at me.com (Nate Begeman)
Date: Tue, 02 Jun 2009 09:59:15 -0700
Subject: [LLVMdev] MachO writer test cases
In-Reply-To: <2658EA9154194EF9A82CF6E330526E70@HPLAPTOP>
References: <0A6EFE1F7943443C9EC8B8B9D2F31A71@HPLAPTOP>
	<77A779F8-048A-4B9C-B708-78DF37C104ED@me.com>
	<2658EA9154194EF9A82CF6E330526E70@HPLAPTOP>
Message-ID: <C1501A73-8998-400F-99EC-03B7A55F298B@me.com>


On Jun 1, 2009, at 12:18 PM, Aaron Gray wrote:

> Nate,
>
> Right, okay. I was also planning on looking at what the assembly  
> output generates and "emulating" its output.

Sure.  I was using the source for 'as' and 'ld' as my guide when I was  
working on it.

>
> So I should be able to use the 'test/CodeGen/PowerPC' tests once I  
> have augmented the MachO Writer PowerPC output.

Sounds good.

Nate

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090602/9e9d1783/attachment.html>

From aaronngray.lists at googlemail.com  Tue Jun  2 10:15:54 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Tue, 2 Jun 2009 18:15:54 +0100
Subject: [LLVMdev] MachO writer test cases
References: <0A6EFE1F7943443C9EC8B8B9D2F31A71@HPLAPTOP><77A779F8-048A-4B9C-B708-78DF37C104ED@me.com><2658EA9154194EF9A82CF6E330526E70@HPLAPTOP>
	<C1501A73-8998-400F-99EC-03B7A55F298B@me.com>
Message-ID: <C2C7186240A24673B5DA686A04D4B082@HPLAPTOP>

Nate, thanks for verifying things.

Aaron

  ----- Original Message ----- 
  From: Nate Begeman 
  To: LLVM Developers Mailing List 
  Sent: Tuesday, June 02, 2009 5:59 PM
  Subject: Re: [LLVMdev] MachO writer test cases




  On Jun 1, 2009, at 12:18 PM, Aaron Gray wrote:


    Nate,

    Right, okay. I was also planning on looking at what the assembly output generates and "emulating" its output.


  Sure.  I was using the source for 'as' and 'ld' as my guide when I was working on it.



    So I should be able to use the 'test/CodeGen/PowerPC' tests once I have augmented the MachO Writer PowerPC output.


  Sounds good.


  Nate




------------------------------------------------------------------------------


  _______________________________________________
  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.llvm.org/pipermail/llvm-dev/attachments/20090602/69c15d74/attachment.html>

From clattner at apple.com  Tue Jun  2 10:16:20 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 2 Jun 2009 10:16:20 -0700
Subject: [LLVMdev] RFC: Atomics.h
In-Reply-To: <a16b1b15-5238-4416-b712-0ac0ea909c5a@h18g2000yqj.googlegroups.com>
References: <6A0323F4-704E-43F5-9176-DF8F25EA0B65@mac.com>
	<295e750a0905161500g788765edr2da536519c4b7873@mail.gmail.com>
	<E14861AF-99D7-43F5-BEF8-81FD30FEA2C6@mac.com>
	<BCAD37BF-1B87-4A7D-AFBE-293B1F8A07E3@apple.com>
	<6BF939BD-723F-40B9-8E53-BBE414631991@mac.com>
	<da5dd333-4a61-440b-a037-6612f2b4e437@3g2000yqk.googlegroups.com>
	<B30EFF3F-2A50-458D-977B-452BE7D0C288@mac.com>
	<a16b1b15-5238-4416-b712-0ac0ea909c5a@h18g2000yqj.googlegroups.com>
Message-ID: <8E38567B-688B-4800-88B8-EA2F9F1896E6@apple.com>


On Jun 1, 2009, at 11:17 PM, Jonathan Ragan-Kelley wrote:

> Yes, indeed.

Are they macros or functions?  If macros, why not just #undef them at  
the top of Atomics.h?

-Chris

>
>
> On May 28, 10:41 pm, Owen Anderson <resis... at mac.com> wrote:
>>
>> Wait, it defines MemoryFence() AND MemoryBarrier()??
>>
>> Sheesh, they had to take all the reasonable names.  :-/
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



From duggal at apple.com  Tue Jun  2 10:37:47 2009
From: duggal at apple.com (Abhinav Duggal)
Date: Tue, 2 Jun 2009 10:37:47 -0700
Subject: [LLVMdev] Interested in working on Predictive Commoning
Message-ID: <2C712CB1-1F0E-43DE-9E4D-8ECA5E546D4B@apple.com>

Hi all,
I am a graduate student at Stony Brook University and have joined as  
an intern in Debugger's group.. I am interested in contributing to  
llvm in my spare time.I would like to work on Predictive Commoning  
transformation.I have some experience working on GCC plugins but my  
major experience has been into Linux Kernel and Architecture in general.
With Regards,
Abhinav Duggal.	


From mburke at ea.com  Tue Jun  2 10:39:08 2009
From: mburke at ea.com (Burke, Max)
Date: Tue, 2 Jun 2009 10:39:08 -0700
Subject: [LLVMdev] RFC: Atomics.h
In-Reply-To: <8E38567B-688B-4800-88B8-EA2F9F1896E6@apple.com>
References: <6A0323F4-704E-43F5-9176-DF8F25EA0B65@mac.com>
	<295e750a0905161500g788765edr2da536519c4b7873@mail.gmail.com>
	<E14861AF-99D7-43F5-BEF8-81FD30FEA2C6@mac.com>
	<BCAD37BF-1B87-4A7D-AFBE-293B1F8A07E3@apple.com>
	<6BF939BD-723F-40B9-8E53-BBE414631991@mac.com>
	<da5dd333-4a61-440b-a037-6612f2b4e437@3g2000yqk.googlegroups.com>
	<B30EFF3F-2A50-458D-977B-452BE7D0C288@mac.com>
	<a16b1b15-5238-4416-b712-0ac0ea909c5a@h18g2000yqj.googlegroups.com>
	<8E38567B-688B-4800-88B8-EA2F9F1896E6@apple.com>
Message-ID: <FFFE2FAA3C3DB84494A4040F8A875A637503C68E1A@NA-MAIL-1-3.rws.ad.ea.com>

MemoryFence() and MemoryBarrier() are both macros so #undef'ing them should work and if their functionality is needed then the Win32 ReadBarrier/WriteBarrier/ReadWriteBarrier functions (or their underscore-prefixed intrinsics) should be substitutable.

-Max


-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner
Sent: Tuesday, June 02, 2009 10:16 AM
To: LLVM Developers Mailing List
Subject: Re: [LLVMdev] RFC: Atomics.h


On Jun 1, 2009, at 11:17 PM, Jonathan Ragan-Kelley wrote:

> Yes, indeed.

Are they macros or functions?  If macros, why not just #undef them at  
the top of Atomics.h?

-Chris




From zaimoni at zaimoni.com  Tue Jun  2 10:47:12 2009
From: zaimoni at zaimoni.com (Kenneth Boyd)
Date: Tue, 02 Jun 2009 12:47:12 -0500
Subject: [LLVMdev] RFC: Atomics.h
In-Reply-To: <56BE3801-56E1-46C3-8B87-C56D74BD67A2@mac.com>
References: <6A0323F4-704E-43F5-9176-DF8F25EA0B65@mac.com>	<295e750a0905161500g788765edr2da536519c4b7873@mail.gmail.com>	<E14861AF-99D7-43F5-BEF8-81FD30FEA2C6@mac.com>	<BCAD37BF-1B87-4A7D-AFBE-293B1F8A07E3@apple.com>	<6BF939BD-723F-40B9-8E53-BBE414631991@mac.com>	<da5dd333-4a61-440b-a037-6612f2b4e437@3g2000yqk.googlegroups.com>	<B30EFF3F-2A50-458D-977B-452BE7D0C288@mac.com>	<a16b1b15-5238-4416-b712-0ac0ea909c5a@h18g2000yqj.googlegroups.com>
	<56BE3801-56E1-46C3-8B87-C56D74BD67A2@mac.com>
Message-ID: <4A2565A0.7010503@zaimoni.com>

Owen Anderson wrote:
> Is this actually the case?  I can't find it documented anywhere on 
> MSDN or the rest of the internet.

C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include>grep -n -F 
MemoryFence WinNT.h
2231:#define MemoryFence _mm_mfence

C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include>grep -n -F 
MemoryBarrier WinNT.h
2288:#define MemoryBarrier __faststorefence
3362:MemoryBarrier (
4890:#define MemoryBarrier           __mf

Also, I have absolutely no problem using MSDN search to find these links:
http://blogs.msdn.com/itgoestoeleven/archive/2008/03/11/the-joys-of-compiler-and-processor-reordering-why-you-need-the-read-side-barrier.aspx  
[MemoryFence]
http://msdn.microsoft.com/en-us/library/ms684208.aspx [MemoryBarrier]

Kenneth Boyd



From aaronngray.lists at googlemail.com  Tue Jun  2 10:56:10 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Tue, 2 Jun 2009 18:56:10 +0100
Subject: [LLVMdev] Origin of DEBUG and EH label values
References: <16A62A187FD14180AD1A537F21E5311A@HPLAPTOP>
	<352a1fb20906011538r7a57ec1lf1e8db3be8344dd7@mail.gmail.com>
Message-ID: <76DCC5E506C14CF199E44C04FE3B3516@HPLAPTOP>

>On Sun, May 3, 2009 at 3:41 PM, Aaron Gray
><aaronngray.lists at googlemail.com> wrote:
>> Where do DEBUG and EH label values originate from ?
>>
>> Where's their allocator ?
>>
>> I am looking at some code in X86CodeEmitter.cpp line 574, where a labels
>> value is extraced from an operand.
>>
>> But dont know where to look in the frontend or middle end to find the
>> LabelID allocator.
>
>See how Intrinsic::dbg_* are lowered by SelectionDAGBuild.cpp and 
>FastISel.cpp

Thanks Devang, I will study it when I get some time and the right head on, 
this is new territory for me.

Aaron


_______________________________________________
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  Tue Jun  2 11:10:38 2009
From: gohman at apple.com (Dan Gohman)
Date: Tue, 2 Jun 2009 11:10:38 -0700
Subject: [LLVMdev] LiveValues Pass
In-Reply-To: <4f5edbea0906020554h6f8d6fbfp3ea5d2e74b8077@mail.gmail.com>
References: <4f5edbea0906020554h6f8d6fbfp3ea5d2e74b8077@mail.gmail.com>
Message-ID: <87892836-C3D5-4044-9D28-0561A3F54F20@apple.com>


On Jun 2, 2009, at 5:54 AM, Rotem Varon wrote:
>
> This questions are on the LiveValues pass:
> Do i need to set the "LiveValues" pass in the PassManager as a  
> prerequisite? if so how do i get the results ?

Yes; it's a standard analysis pass. See
http://llvm.org/docs/WritingAnLLVMPass.html
for information about interactions between passes.

> How do i get/use the results of LiveValuse pass in my pass?
> Is there documentation in the LLVM site (beside of the comments on  
> the file)?
> Can i simply use its public function ?

There are Doxygen comments which can be read either in the file itself
or via http://llvm.org/doxygen/

Dan



From wjjeon at gmail.com  Tue Jun  2 11:58:21 2009
From: wjjeon at gmail.com (Won J Jeon)
Date: Tue, 2 Jun 2009 13:58:21 -0500
Subject: [LLVMdev] Current status of ARM backend (system-level support
	specifically) on LLVM?
Message-ID: <b8b15f5e0906021158y549b9ce1m84b64636b9ffdf2e@mail.gmail.com>

Hello all,

We just started to look at how we could use LLVM to secure ARM-based mobile
system from malware like overriding pointers to system functions and causing
memory overflow. I'm wondering how the current ARM backend work on the
current LLVM release. Does it have any support for ARM system-level
instructions to change the page tables or switching tasks? I appreciate your
help and comment.

Regards,
Won
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090602/d5777aab/attachment.html>

From resistor at mac.com  Tue Jun  2 12:06:33 2009
From: resistor at mac.com (Owen Anderson)
Date: Tue, 02 Jun 2009 12:06:33 -0700
Subject: [LLVMdev] RFC: Atomics.h
In-Reply-To: <4A2565A0.7010503@zaimoni.com>
References: <6A0323F4-704E-43F5-9176-DF8F25EA0B65@mac.com>
	<295e750a0905161500g788765edr2da536519c4b7873@mail.gmail.com>
	<E14861AF-99D7-43F5-BEF8-81FD30FEA2C6@mac.com>
	<BCAD37BF-1B87-4A7D-AFBE-293B1F8A07E3@apple.com>
	<6BF939BD-723F-40B9-8E53-BBE414631991@mac.com>
	<da5dd333-4a61-440b-a037-6612f2b4e437@3g2000yqk.googlegroups.com>
	<B30EFF3F-2A50-458D-977B-452BE7D0C288@mac.com>
	<a16b1b15-5238-4416-b712-0ac0ea909c5a@h18g2000yqj.googlegroups.com>
	<56BE3801-56E1-46C3-8B87-C56D74BD67A2@mac.com>
	<4A2565A0.7010503@zaimoni.com>
Message-ID: <7BDA3716-2E17-43EA-8A10-FA741FCC8E84@mac.com>

This should be fixed in TOT, then.

--Owen

On Jun 2, 2009, at 10:47 AM, Kenneth Boyd wrote:

> Owen Anderson wrote:
>> Is this actually the case?  I can't find it documented anywhere on
>> MSDN or the rest of the internet.
>
> C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include>grep -n -F
> MemoryFence WinNT.h
> 2231:#define MemoryFence _mm_mfence
>
> C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include>grep -n -F
> MemoryBarrier WinNT.h
> 2288:#define MemoryBarrier __faststorefence
> 3362:MemoryBarrier (
> 4890:#define MemoryBarrier           __mf
>
> Also, I have absolutely no problem using MSDN search to find these  
> links:
> http://blogs.msdn.com/itgoestoeleven/archive/2008/03/11/the-joys-of-compiler-and-processor-reordering-why-you-need-the-read-side-barrier.aspx
> [MemoryFence]
> http://msdn.microsoft.com/en-us/library/ms684208.aspx [MemoryBarrier]
>
> Kenneth Boyd
>
> _______________________________________________
> 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: 2620 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090602/a2f8a3ea/attachment.bin>

From llvm at assumetheposition.nl  Tue Jun  2 12:14:06 2009
From: llvm at assumetheposition.nl (Paul Melis)
Date: Tue, 02 Jun 2009 21:14:06 +0200
Subject: [LLVMdev] Ubuntu: no .eh_frame_hdr table will be created
Message-ID: <4A2579FE.8000100@assumetheposition.nl>

Hi,
While building svn using CMake on an Ubuntu 9.04 system (gcc 4.3.3,
binutils 2.19.1, 32-bit kernel and libs):

Linking CXX executable ../../bin/llvm-dis
[ 93%] Built target llvm-dis
Scanning dependencies of target llc
[ 93%] Building CXX object tools/llc/CMakeFiles/llc.dir/llc.cpp.o
Linking CXX executable ../../bin/llc
/usr/bin/ld: error in ../../lib/./LLVMX86AsmPrinter.o(.eh_frame); no
.eh_frame_hdr table will created.
/usr/bin/ld: error in ../../lib/./LLVMX86CodeGen.o(.eh_frame); no
.eh_frame_hdr table will be created.
[ 93%] Built target llc
Scanning dependencies of target llvm-ranlib

Scanning dependencies of target lli
[ 95%] Building CXX object tools/lli/CMakeFiles/lli.dir/lli.cpp.o
Linking CXX executable ../../bin/lli
/usr/bin/ld: error in ../../lib/./LLVMX86CodeGen.o(.eh_frame); no
.eh_frame_hdr table will be created.
/usr/bin/ld: error in ../../lib/./LLVMInterpreter.o(.eh_frame); no
.eh_frame_hdr table will be created.
/usr/bin/ld: error in ../../lib/./LLVMExecutionEngine.o(.eh_frame); no
.eh_frame_hdr table will be created.
[ 95%] Built target lli
Scanning dependencies of target llvm-extract

And similar for the BrainF, Fibonacci, Kaleidoscope and ParallelJIT examples


This seems to have come up for a 64-bit build before, due to certain
changes in the LLVM:
http://markmail.org/message/njw2rxsdv446ojrx


Did this issue reappear (but on 32-bit)?

Regards,
Paul





From eli.friedman at gmail.com  Tue Jun  2 13:08:29 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Tue, 2 Jun 2009 13:08:29 -0700
Subject: [LLVMdev] Current status of ARM backend (system-level support
	specifically) on LLVM?
In-Reply-To: <b8b15f5e0906021158y549b9ce1m84b64636b9ffdf2e@mail.gmail.com>
References: <b8b15f5e0906021158y549b9ce1m84b64636b9ffdf2e@mail.gmail.com>
Message-ID: <f5aa3e9b0906021308g3e10924if868def294a8bda6@mail.gmail.com>

On Tue, Jun 2, 2009 at 11:58 AM, Won J Jeon<wjjeon at gmail.com> wrote:
> Hello all,
>
> We just started to look at how we could use LLVM to secure ARM-based mobile
> system from malware like overriding pointers to system functions and causing
> memory overflow. I'm wondering how the current ARM backend work on the
> current LLVM release.

It's stabe enough to be usable, as far as I know.

> Does it have any support for ARM system-level
> instructions to change the page tables or switching tasks?

You can use inline assembly for this sort of thing.

-Eli



From simmon12 at cs.uiuc.edu  Tue Jun  2 13:09:45 2009
From: simmon12 at cs.uiuc.edu (Patrick Alexander Simmons)
Date: Tue, 02 Jun 2009 14:09:45 -0600
Subject: [LLVMdev] Including / Linking with Pool Allocation
Message-ID: <4A258709.8070706@cs.uiuc.edu>

Hi,

I'm starting to code a pass which uses the analysis results of pool 
allocation, and I've run into a bit of a snag.  Following the advice at 
[http://llvm.org/docs/WritingAnLLVMPass.html], I've put my new pass in 
the lib/Transforms subdirectory of the llvm checkout.  I have the pool 
allocation transformation checked out in projects/llvm-poolalloc.

My problem is that the pool allocation header files are not in my pass's 
include path.  I assume I need to modify the Makefile somehow to correct 
this and that I should perhaps also add a line to make it link with the 
pool allocation .so files, but I don't know the proper way to do this.  
Could someone help?

Thanks,
--Patrick


From superoptimizer at gmail.com  Tue Jun  2 14:38:28 2009
From: superoptimizer at gmail.com (Mark Lacey)
Date: Tue, 2 Jun 2009 14:38:28 -0700
Subject: [LLVMdev] Is there a control dependence graph builder?
Message-ID: <f5c3a98b0906021438v420770a4wa6fb38495d088c03@mail.gmail.com>

Hi,

In browsing through the LLVM source, I don't currently see an implementation
for a control dependence graph builder. Am I overlooking something?

It doesn't look like LLVM currently provides a way to build the
post-dominance frontier of the reverse CFG, either. Dominators.h mentions
forward dominators, but I believe all this is referring to is dominators as
opposed to post-dominators, not dominators on the CFG versus dominators on
the reverse-CFG.

I just wanted to make certain I'm not overlooking anything before I decide
if I want to go off and build this myself.

Thanks,

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090602/9b6bca0e/attachment.html>

From eli.friedman at gmail.com  Tue Jun  2 15:05:53 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Tue, 2 Jun 2009 15:05:53 -0700
Subject: [LLVMdev] Is there a control dependence graph builder?
In-Reply-To: <f5c3a98b0906021438v420770a4wa6fb38495d088c03@mail.gmail.com>
References: <f5c3a98b0906021438v420770a4wa6fb38495d088c03@mail.gmail.com>
Message-ID: <f5aa3e9b0906021505s3ecc5585ja4b9273353b4478b@mail.gmail.com>

On Tue, Jun 2, 2009 at 2:38 PM, Mark Lacey<superoptimizer at gmail.com> wrote:
> In browsing through the LLVM source, I don't currently see an implementation
> for a control dependence graph builder. Am I overlooking something?

No, I don't think there is one.  I think an implementation would be
welcome if you're willing to contribute one.

> It doesn't look like LLVM currently provides a way to build the
> post-dominance frontier of the reverse CFG, either. Dominators.h mentions
> forward dominators, but I believe all this is referring to is dominators as
> opposed to post-dominators, not dominators on the CFG versus dominators on
> the reverse-CFG.

Try PostDominators.h.

-Eli


From vgrover528 at gmail.com  Tue Jun  2 15:13:28 2009
From: vgrover528 at gmail.com (Vinod Grover)
Date: Tue, 2 Jun 2009 15:13:28 -0700
Subject: [LLVMdev] Is there a control dependence graph builder?
In-Reply-To: <f5c3a98b0906021438v420770a4wa6fb38495d088c03@mail.gmail.com>
References: <f5c3a98b0906021438v420770a4wa6fb38495d088c03@mail.gmail.com>
Message-ID: <35657f570906021513s7cd75d8bh2b269801182be31@mail.gmail.com>

the DominanceFrontierBase class constructor specifies a parameter isPostDom
which I assume builds the reverse dominance frontier

On Tue, Jun 2, 2009 at 2:38 PM, Mark Lacey <superoptimizer at gmail.com> wrote:

> Hi,
>
> In browsing through the LLVM source, I don't currently see an
> implementation for a control dependence graph builder. Am I overlooking
> something?
>
> It doesn't look like LLVM currently provides a way to build the
> post-dominance frontier of the reverse CFG, either. Dominators.h mentions
> forward dominators, but I believe all this is referring to is dominators as
> opposed to post-dominators, not dominators on the CFG versus dominators on
> the reverse-CFG.
>
> I just wanted to make certain I'm not overlooking anything before I decide
> if I want to go off and build this myself.
>
> Thanks,
>
> Mark
>
>
> _______________________________________________
> 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.llvm.org/pipermail/llvm-dev/attachments/20090602/e43ece3b/attachment.html>

From criswell at cs.uiuc.edu  Tue Jun  2 15:35:20 2009
From: criswell at cs.uiuc.edu (John Criswell)
Date: Tue, 2 Jun 2009 17:35:20 -0500
Subject: [LLVMdev] Including / Linking with Pool Allocation
In-Reply-To: <4A258709.8070706@cs.uiuc.edu>
References: <4A258709.8070706@cs.uiuc.edu>
Message-ID: <4A25A928.3080707@cs.uiuc.edu>

Patrick Alexander Simmons wrote:
> Hi,
>
> I'm starting to code a pass which uses the analysis results of pool 
> allocation, and I've run into a bit of a snag.  Following the advice at 
> [http://llvm.org/docs/WritingAnLLVMPass.html], I've put my new pass in 
> the lib/Transforms subdirectory of the llvm checkout.  I have the pool 
> allocation transformation checked out in projects/llvm-poolalloc.
>   
First, while I am a firm believer in the Writing an LLVM Pass document,
it is giving you bad advice (IMHO).  What you want to do is to create an
LLVM Project; that way, your code is outside of the LLVM source tree and
can be more easily maintained in a revision control system of your
choice.  Information on LLVM projects is here:
http://llvm.org/docs/Projects.html.

> My problem is that the pool allocation header files are not in my pass's 
> include path.  I assume I need to modify the Makefile somehow to correct 
> this and that I should perhaps also add a line to make it link with the 
> pool allocation .so files, but I don't know the proper way to do this.  
> Could someone help?
>   
To add extra flags to the gcc command line during compilation, use the
following in the Makefile:

CFLAGS += -I<directory of include files>
CXXFLAGS += -I<directory of include files>
CPPFLAGS += -I<directory of include files>

This will tell make to use the -I flag to find the header files you need.

You shouldn't need to link in poolalloc.so; you will either use the
-load option to load poolalloc.so and your pass into the opt program, or
you will need to write your own program (akin to the pa program in
poolalloc/tools/pa) that links in your pass and poolalloc.so and
schedules the pool allocation pass and your pass to be run by the
PassManager.

-- John T.

P.S. Note that I've used poolalloc.so as the name of the dynamically
loadable object that contains the pool allocation pass.  I'm not sure if
I've got the name correct, and the name will vary depending on OS (e.g.,
poolalloc.dylib on Mac OS X).

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



From superoptimizer at gmail.com  Tue Jun  2 16:19:01 2009
From: superoptimizer at gmail.com (Mark Lacey)
Date: Tue, 2 Jun 2009 16:19:01 -0700
Subject: [LLVMdev] Is there a control dependence graph builder?
In-Reply-To: <f5aa3e9b0906021505s3ecc5585ja4b9273353b4478b@mail.gmail.com>
References: <f5c3a98b0906021438v420770a4wa6fb38495d088c03@mail.gmail.com>
	<f5aa3e9b0906021505s3ecc5585ja4b9273353b4478b@mail.gmail.com>
Message-ID: <f5c3a98b0906021619v6001f83wd73c66485c21b592@mail.gmail.com>

On Tue, Jun 2, 2009 at 3:05 PM, Eli Friedman <eli.friedman at gmail.com> wrote:

>
> Try PostDominators.h.
>

Yes, I seemed to have blanked out there for minute and thought I needed
something other than the post-dominance frontier.

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090602/14b37457/attachment.html>

From eric at brouhaha.com  Tue Jun  2 17:45:40 2009
From: eric at brouhaha.com (Eric Smith)
Date: Tue, 02 Jun 2009 17:45:40 -0700
Subject: [LLVMdev] LLVM-gcc for Ada
Message-ID: <4A25C7B4.5000600@brouhaha.com>

Thanks for the suggestion, Andre.  I downloaded GNAT GPL 2007, and 
followed the directions on your web page.  Now I get a lot of C++ 
errors.  In fact, the output I captured to a log file is over six 
megabytes just from the start of the problem command to the termination 
of the make.  I'm obviously not going to include it all here, but the 
command and the first few errors are copied below.

Any idea what might be wrong now?

Best regards,
Eric


/usr/bin/gcc   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings 
-Wstrict-prototypes -Wmissin\
g-prototypes -Wold-style-definition -Wmissing-format-attribute 
-fno-common   -DHAVE_CO\
NFIG_H  -o cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o 
c-pragma.o c-de\
cl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o 
c-semantics.o \
c-incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o 
c-objc-common.o c-dump.o\
 c-pch.o c-parser.o  c-gimplify.o tree-mudflap.o c-pretty-print.o 
c-omp.o dummy-checks\
um.o \
          llvm-main.o tree-browser.o libbackend.a ../libcpp/libcpp.a 
/home/eric/llvm/l\
lvm-objects/Release/lib/libLLVMBitReader.a 
/home/eric/llvm/llvm-objects/Release/lib/li\
bLLVMipo.a /home/eric/llvm/llvm-objects/Release/lib/libLLVMBitWriter.a 
/home/eric/llvm\
/llvm-objects/Release/lib/LLVMX86AsmPrinter.o 
/home/eric/llvm/llvm-objects/Release/lib\
/LLVMX86CodeGen.o 
/home/eric/llvm/llvm-objects/Release/lib/libLLVMSelectionDAG.a /home\
/eric/llvm/llvm-objects/Release/lib/libLLVMAsmPrinter.a 
/home/eric/llvm/llvm-objects/R\
elease/lib/libLLVMCodeGen.a 
/home/eric/llvm/llvm-objects/Release/lib/libLLVMScalarOpts\
.a /home/eric/llvm/llvm-objects/Release/lib/libLLVMTransformUtils.a 
/home/eric/llvm/ll\
vm-objects/Release/lib/libLLVMipa.a 
/home/eric/llvm/llvm-objects/Release/lib/libLLVMAn\
alysis.a /home/eric/llvm/llvm-objects/Release/lib/libLLVMTarget.a 
/home/eric/llvm/llvm\
-objects/Release/lib/libLLVMCore.a 
/home/eric/llvm/llvm-objects/Release/lib/libLLVMSup\
port.a /home/eric/llvm/llvm-objects/Release/lib/libLLVMSystem.a 
../libcpp/libcpp.a   .\
./libiberty/libiberty.a ../libdecnumber/libdecnumber.a 
-L/home/eric/llvm/llvm-objects/\
Release/lib  -lpthread -ldl -lm -lelf
llvm-main.o: In function `__static_initialization_and_destruction_0':
/usr/lib/gcc/i386-redhat-linux/4.3.2/../../../../include/c++/4.3.2/iostream:77: 
undefi\
ned reference to `std::ios_base::Init::Init()'
/usr/lib/gcc/i386-redhat-linux/4.3.2/../../../../include/c++/4.3.2/iostream:77: 
undefi\
ned reference to `std::ios_base::Init::~Init()'
llvm-main.o:(.eh_frame+0x11): undefined reference to `__gxx_personality_v0'
libbackend.a(llvm-backend.o): In function `llvm_asm_file_start':
/home/eric/llvm/llvm-gcc-4.2-objects/gcc/../../llvm-gcc-4.2/gcc/llvm-backend.cpp:566: 
\
undefined reference to `operator new(unsigned int)'
libbackend.a(llvm-backend.o): In function `basic_ios':
/usr/lib/gcc/i386-redhat-linux/4.3.2/../../../../include/c++/4.3.2/bits/basic_ios.h:45\
6: undefined reference to `std::ios_base::ios_base()'
/usr/lib/gcc/i386-redhat-linux/4.3.2/../../../../include/c++/4.3.2/bits/basic_ios.h:45\
6: undefined reference to `vtable for std::basic_ios<char, 
std::char_traits<char> >'
libbackend.a(llvm-backend.o): In function `basic_ostream':
/usr/lib/gcc/i386-redhat-linux/4.3.2/../../../../include/c++/4.3.2/ostream:87: 
undefin\
ed reference to `std::basic_ios<char, std::char_traits<char> 
 >::init(std::basic_stream\
buf<char, std::char_traits<char> >*)'





From andrelct at dcc.ufmg.br  Tue Jun  2 18:18:08 2009
From: andrelct at dcc.ufmg.br (Andre Tavares)
Date: Tue, 02 Jun 2009 22:18:08 -0300
Subject: [LLVMdev] LLVM-gcc for Ada
In-Reply-To: <4A25C7B4.5000600@brouhaha.com>
References: <4A25C7B4.5000600@brouhaha.com>
Message-ID: <4A25CF50.9080802@dcc.ufmg.br>

Eric Smith wrote:
> Thanks for the suggestion, Andre.  I downloaded GNAT GPL 2007, and 
> followed the directions on your web page.  Now I get a lot of C++ 
> errors.  In fact, the output I captured to a log file is over six 
> megabytes just from the start of the problem command to the termination 
> of the make.  I'm obviously not going to include it all here, but the 
> command and the first few errors are copied below.
>
> Any idea what might be wrong now?
>
> Best regards,
> Eric
>
>
> /usr/bin/gcc   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings 
> -Wstrict-prototypes -Wmissin\
> g-prototypes -Wold-style-definition -Wmissing-format-attribute 
> -fno-common   -DHAVE_CO\
> NFIG_H  -o cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o 
> c-pragma.o c-de\
> cl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o 
> c-semantics.o \
> c-incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o 
> c-objc-common.o c-dump.o\
>  c-pch.o c-parser.o  c-gimplify.o tree-mudflap.o c-pretty-print.o 
> c-omp.o dummy-checks\
> um.o \
>           llvm-main.o tree-browser.o libbackend.a ../libcpp/libcpp.a 
> /home/eric/llvm/l\
> lvm-objects/Release/lib/libLLVMBitReader.a 
> /home/eric/llvm/llvm-objects/Release/lib/li\
> bLLVMipo.a /home/eric/llvm/llvm-objects/Release/lib/libLLVMBitWriter.a 
> /home/eric/llvm\
> /llvm-objects/Release/lib/LLVMX86AsmPrinter.o 
> /home/eric/llvm/llvm-objects/Release/lib\
> /LLVMX86CodeGen.o 
> /home/eric/llvm/llvm-objects/Release/lib/libLLVMSelectionDAG.a /home\
> /eric/llvm/llvm-objects/Release/lib/libLLVMAsmPrinter.a 
> /home/eric/llvm/llvm-objects/R\
> elease/lib/libLLVMCodeGen.a 
> /home/eric/llvm/llvm-objects/Release/lib/libLLVMScalarOpts\
> .a /home/eric/llvm/llvm-objects/Release/lib/libLLVMTransformUtils.a 
> /home/eric/llvm/ll\
> vm-objects/Release/lib/libLLVMipa.a 
> /home/eric/llvm/llvm-objects/Release/lib/libLLVMAn\
> alysis.a /home/eric/llvm/llvm-objects/Release/lib/libLLVMTarget.a 
> /home/eric/llvm/llvm\
> -objects/Release/lib/libLLVMCore.a 
> /home/eric/llvm/llvm-objects/Release/lib/libLLVMSup\
> port.a /home/eric/llvm/llvm-objects/Release/lib/libLLVMSystem.a 
> ../libcpp/libcpp.a   .\
> ./libiberty/libiberty.a ../libdecnumber/libdecnumber.a 
> -L/home/eric/llvm/llvm-objects/\
> Release/lib  -lpthread -ldl -lm -lelf
> llvm-main.o: In function `__static_initialization_and_destruction_0':
> /usr/lib/gcc/i386-redhat-linux/4.3.2/../../../../include/c++/4.3.2/iostream:77: 
> undefi\
> ned reference to `std::ios_base::Init::Init()'
> /usr/lib/gcc/i386-redhat-linux/4.3.2/../../../../include/c++/4.3.2/iostream:77: 
> undefi\
> ned reference to `std::ios_base::Init::~Init()'
> llvm-main.o:(.eh_frame+0x11): undefined reference to `__gxx_personality_v0'
> libbackend.a(llvm-backend.o): In function `llvm_asm_file_start':
> /home/eric/llvm/llvm-gcc-4.2-objects/gcc/../../llvm-gcc-4.2/gcc/llvm-backend.cpp:566: 
> \
> undefined reference to `operator new(unsigned int)'
> libbackend.a(llvm-backend.o): In function `basic_ios':
> /usr/lib/gcc/i386-redhat-linux/4.3.2/../../../../include/c++/4.3.2/bits/basic_ios.h:45\
> 6: undefined reference to `std::ios_base::ios_base()'
> /usr/lib/gcc/i386-redhat-linux/4.3.2/../../../../include/c++/4.3.2/bits/basic_ios.h:45\
> 6: undefined reference to `vtable for std::basic_ios<char, 
> std::char_traits<char> >'
> libbackend.a(llvm-backend.o): In function `basic_ostream':
> /usr/lib/gcc/i386-redhat-linux/4.3.2/../../../../include/c++/4.3.2/ostream:87: 
> undefin\
> ed reference to `std::basic_ios<char, std::char_traits<char> 
>  >::init(std::basic_stream\
> buf<char, std::char_traits<char> >*)'
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>   
In which step did this happen? make?

-- 
Andre Tavares
Master Student in Computer Science - UFMG - Brasil
http://dcc.ufmg.br/~andrelct



From robert at muth.org  Tue Jun  2 18:26:31 2009
From: robert at muth.org (robert muth)
Date: Tue, 2 Jun 2009 21:26:31 -0400
Subject: [LLVMdev] patch for llc/ARM: added mechanism to move switch tables
	from .text -> .data; also cleanup and documentation
Message-ID: <8e3491100906021826p4530f341xbb168d260c21342e@mail.gmail.com>

Hi:

This is my first patch submission. Hopefully, this is the proper the protocol.
Attached is a patch for the llc ARM backend:

Added mechanism to generate switch table in a data section
rather than having it interleaved with the code.
This is controlled by command line flags and off by default.
Also, tried to document and improve the code where I modified it.

Robert
-------------- next part --------------
Index: lib/Target/ARM/ARMISelLowering.h
===================================================================
--- lib/Target/ARM/ARMISelLowering.h	(revision 72728)
+++ lib/Target/ARM/ARMISelLowering.h	(working copy)
@@ -147,9 +147,10 @@
     /// make the right decision when generating code for different targets.
     const ARMSubtarget *Subtarget;
 
-    /// ARMPCLabelIndex - Keep track the number of ARM PC labels created.
-    ///
+    /// ARMPCLabelIndex - Keep track of the number of ARM PC labels created.
     unsigned ARMPCLabelIndex;
+    /// ARMJumpTableIndex - Keep track of the number ofJump Tables
+    unsigned ARMJumpTableIndex;
 
     SDValue LowerMemOpCallTo(CallSDNode *TheCall, SelectionDAG &DAG,
                              const SDValue &StackPtr, const CCValAssign &VA,
Index: lib/Target/ARM/ARMConstantPoolValue.h
===================================================================
--- lib/Target/ARM/ARMConstantPoolValue.h	(revision 72728)
+++ lib/Target/ARM/ARMConstantPoolValue.h	(working copy)
@@ -25,6 +25,7 @@
   enum ARMCPKind {
     CPValue,
     CPNonLazyPtr,
+    CPDataSegmentJumpTable,
     CPStub
   };
 }
@@ -54,7 +55,6 @@
   ARMConstantPoolValue(GlobalValue *GV, ARMCP::ARMCPKind Kind,
                        const char *Modifier);
 
-
   GlobalValue *getGV() const { return GV; }
   const char *getSymbol() const { return S; }
   const char *getModifier() const { return Modifier; }
@@ -63,6 +63,9 @@
   unsigned getLabelId() const { return LabelId; }
   bool isNonLazyPointer() const { return Kind == ARMCP::CPNonLazyPtr; }
   bool isStub() const { return Kind == ARMCP::CPStub; }
+  bool isValue() const { return Kind == ARMCP::CPValue; }
+  bool isDataSegmentJumpTable() const {
+    return Kind == ARMCP::CPDataSegmentJumpTable; }
   unsigned char getPCAdjustment() const { return PCAdjust; }
 
   virtual int getExistingMachineCPValue(MachineConstantPool *CP,
Index: lib/Target/ARM/AsmPrinter/ARMAsmPrinter.cpp
===================================================================
--- lib/Target/ARM/AsmPrinter/ARMAsmPrinter.cpp	(revision 72728)
+++ lib/Target/ARM/AsmPrinter/ARMAsmPrinter.cpp	(working copy)
@@ -33,13 +33,19 @@
 #include "llvm/ADT/Statistic.h"
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringSet.h"
+#include "llvm/Support/CommandLine.h"
 #include "llvm/Support/Compiler.h"
 #include "llvm/Support/Mangler.h"
 #include "llvm/Support/MathExtras.h"
 #include "llvm/Support/raw_ostream.h"
 #include <cctype>
+#include <sstream>
 using namespace llvm;
 
+extern cl::opt<bool> FlagOutlineJumpTables;
+cl::opt<std::string> FlagJumpTableSection("jumptable-section",
+                                           cl::init(".data.jtab"));
+
 STATISTIC(EmittedInsts, "Number of machine instrs printed");
 
 namespace {
@@ -139,6 +145,7 @@
     /// EmitMachineConstantPoolValue - Print a machine constantpool value to
     /// the .s file.
     virtual void EmitMachineConstantPoolValue(MachineConstantPoolValue *MCPV) {
+      // NOTE: A lot of this code is replicated in  ARMConstantPoolValue::print
       printDataDirective(MCPV->getType());
 
       ARMConstantPoolValue *ACPV = static_cast<ARMConstantPoolValue*>(MCPV);
@@ -155,8 +162,13 @@
       } else if (ACPV->isStub()) {
         FnStubs.insert(Name);
         printSuffixedName(Name, "$stub");
-      } else
+      } else if (ACPV->isDataSegmentJumpTable()) {
+        // requires synchronization with code (grep for "$jumptable$")
+        O << Name << "$jumptable$" << ACPV->getLabelId();
+      } else {
+        assert(ACPV->isValue() && "unknown CP kind");
         O << Name;
+      }
       if (ACPV->hasModifier()) O << "(" << ACPV->getModifier() << ")";
       if (ACPV->getPCAdjustment() != 0) {
         O << "-(" << TAI->getPrivateGlobalPrefix() << "PC"
@@ -695,12 +707,31 @@
   }
 }
 
+
 void ARMAsmPrinter::printJTBlockOperand(const MachineInstr *MI, int OpNo) {
-  const MachineOperand &MO1 = MI->getOperand(OpNo);
-  const MachineOperand &MO2 = MI->getOperand(OpNo+1); // Unique Id
-  unsigned JTI = MO1.getIndex();
-  O << TAI->getPrivateGlobalPrefix() << "JTI" << getFunctionNumber()
-    << '_' << JTI << '_' << MO2.getImm() << ":\n";
+  std::stringstream  prefix;
+
+  const unsigned JTI =  MI->getOperand(OpNo).getIndex();
+  const unsigned uid = MI->getOperand(OpNo+1).getImm();
+
+  if (FlagOutlineJumpTables) {
+    // needs to be synchronized with ARMConstantPoolValue.cpp
+    prefix << ".T$jumptable$" << uid;
+  } else {
+    // needs to be synchronized with other places in this file
+    prefix  << TAI->getPrivateGlobalPrefix() << "JTI" << getFunctionNumber()
+            << '_' << JTI << '_' << uid;
+  }
+
+  if (FlagOutlineJumpTables) {
+    // switch out of text section
+    O << ".section  " <<  FlagJumpTableSection << ",\"aMS\",%progbits,1\n";
+    O << ".align 4\n";
+    O << "\n\n";
+  }
+
+  // the table label
+  O << prefix.str() << ":\n";
 
   const char *JTEntryDirective = TAI->getJumpTableDirective();
   if (!JTEntryDirective)
@@ -715,24 +746,28 @@
   for (unsigned i = 0, e = JTBBs.size(); i != e; ++i) {
     MachineBasicBlock *MBB = JTBBs[i];
     if (UseSet && JTSets.insert(MBB).second)
-      printPICJumpTableSetLabel(JTI, MO2.getImm(), MBB);
+      printPICJumpTableSetLabel(JTI, uid, MBB);
 
     O << JTEntryDirective << ' ';
     if (UseSet)
-      O << TAI->getPrivateGlobalPrefix() << getFunctionNumber()
-        << '_' << JTI << '_' << MO2.getImm()
-        << "_set_" << MBB->getNumber();
+      O << prefix.str() << "_set_" << MBB->getNumber();
     else if (TM.getRelocationModel() == Reloc::PIC_) {
       printBasicBlockLabel(MBB, false, false, false);
       // If the arch uses custom Jump Table directives, don't calc relative to JT
       if (!TAI->getJumpTableDirective()) 
-        O << '-' << TAI->getPrivateGlobalPrefix() << "JTI"
-          << getFunctionNumber() << '_' << JTI << '_' << MO2.getImm();
+        O << '-' << prefix.str();
     } else
       printBasicBlockLabel(MBB, false, false, false);
     if (i != e-1)
       O << '\n';
   }
+
+  if (FlagOutlineJumpTables) {
+    // switch back into the text section
+    O << "\n\n";
+    O << ".text\n";
+    O << "\n\n";
+  }
 }
 
 
Index: lib/Target/ARM/ARMISelLowering.cpp
===================================================================
--- lib/Target/ARM/ARMISelLowering.cpp	(revision 72728)
+++ lib/Target/ARM/ARMISelLowering.cpp	(working copy)
@@ -36,9 +36,16 @@
 #include "llvm/CodeGen/SelectionDAG.h"
 #include "llvm/Target/TargetOptions.h"
 #include "llvm/ADT/VectorExtras.h"
+#include "llvm/Support/CommandLine.h"
 #include "llvm/Support/MathExtras.h"
+
 using namespace llvm;
 
+
+
+cl::opt<bool> FlagOutlineJumpTables("outline-jumptables",
+                                    cl::desc("move jumptables from text to data"));
+
 static bool CC_ARM_APCS_Custom_f64(unsigned &ValNo, MVT &ValVT, MVT &LocVT,
                                    CCValAssign::LocInfo &LocInfo,
                                    ISD::ArgFlagsTy &ArgFlags,
@@ -1390,27 +1397,119 @@
   return Res;
 }
 
-SDValue ARMTargetLowering::LowerBR_JT(SDValue Op, SelectionDAG &DAG) {
+
+
+// Similar to LowerBR_JT_Inline except that the jumptable
+// is moved to the data segment.
+// This causes a extra load to access the table but keeps the
+// text segment small and avoids some issues with generating PIC
+// Needs to be activated with a commandline flag.
+static SDValue LowerBR_JT_Outline(SDValue Op,
+                                  SelectionDAG &DAG,
+                                  unsigned Num,
+                                  MVT PTy) {
+
   SDValue Chain = Op.getOperand(0);
-  SDValue Table = Op.getOperand(1);
-  SDValue Index = Op.getOperand(2);
-  DebugLoc dl = Op.getDebugLoc();
 
-  MVT PTy = getPointerTy();
-  JumpTableSDNode *JT = cast<JumpTableSDNode>(Table);
+  const JumpTableSDNode *JT = cast<JumpTableSDNode>(Op.getOperand(1));
+  const SDValue Index = Op.getOperand(2);
+
+
+  const DebugLoc dl = Op.getDebugLoc();
+
+  const SDValue UId =  DAG.getConstant(Num, PTy);
+  const SDValue JTI = DAG.getTargetJumpTable(JT->getIndex(), PTy);
+
+  // create a new global symbol for the jumptable
+  ARMConstantPoolValue *CPV = new ARMConstantPoolValue(".T", Num,
+                                          ARMCP::CPDataSegmentJumpTable);
+  const SDValue CPAddr = DAG.getTargetConstantPool(CPV, PTy, 4);
+
+  // An ARM idiosyncrasy: wrap each constant pool entry before accessing it
+  const SDValue Wrapper = DAG.getNode(ARMISD::Wrapper, dl, MVT::i32, CPAddr);
+
+  // Load Table start from constan pool
+  const SDValue Table = DAG.getLoad(PTy, dl, DAG.getEntryNode(), Wrapper, NULL, 0);
+
+  // table entries are 4 bytes, so multiple index by 4
+  const SDValue ScaledIndex = DAG.getNode(ISD::MUL, dl, PTy, Index, DAG.getConstant(4, PTy));
+
+  // add scaled index to table beginning
+  const SDValue TabEntryAddr = DAG.getNode(ISD::ADD, dl, PTy, ScaledIndex, Table);
+  const SDValue JumpTarget = DAG.getLoad(PTy, dl, Chain, TabEntryAddr, NULL, 0);
+
+  return DAG.getNode(ARMISD::BR_JT, dl, MVT::Other, Chain, JumpTarget, JTI, UId);
+}
+
+
+static SDValue LowerBR_JT_Inline(SDValue Op,
+                                 SelectionDAG &DAG,
+                                 bool isPIC,
+                                 MVT PTy) {
+  //  The Jumptable idiom we are aiming for looks somthing like this:
+  //
+  //          .set PCRELV0, (.LJTI9_0_0-(.LPCRELL0+8))
+  //  .LPCRELL0:
+  //          add r3, pc, #PCRELV0
+  //          ldr pc, [r3, +r0, lsl #2]
+  //  .LJTI9_0_0:
+  //          .long    .LBB9_2
+  //          .long    .LBB9_5
+  //          .long    .LBB9_7
+  //          .long    .LBB9_4
+  //          .long    .LBB9_8
+  //
+  // In pic mode the table entries are relative to table beginning
+  // requiring and extra addition
+  //
+  // The code generation logic for ARMISD::BR_JT will also
+  // emit the table (c.f. ARMAsmPrinter::printJTBlockOperand())
+  // Also check  "def BR_JTm" in ARMInstrInfo.td
+
+  // allocate constant pool entry
   ARMFunctionInfo *AFI = DAG.getMachineFunction().getInfo<ARMFunctionInfo>();
-  SDValue UId =  DAG.getConstant(AFI->createJumpTableUId(), PTy);
-  SDValue JTI = DAG.getTargetJumpTable(JT->getIndex(), PTy);
-  Table = DAG.getNode(ARMISD::WrapperJT, dl, MVT::i32, JTI, UId);
-  Index = DAG.getNode(ISD::MUL, dl, PTy, Index, DAG.getConstant(4, PTy));
-  SDValue Addr = DAG.getNode(ISD::ADD, dl, PTy, Index, Table);
-  bool isPIC = getTargetMachine().getRelocationModel() == Reloc::PIC_;
-  Addr = DAG.getLoad(isPIC ? (MVT)MVT::i32 : PTy, dl,
-                     Chain, Addr, NULL, 0);
-  Chain = Addr.getValue(1);
-  if (isPIC)
-    Addr = DAG.getNode(ISD::ADD, dl, PTy, Addr, Table);
-  return DAG.getNode(ARMISD::BR_JT, dl, MVT::Other, Chain, Addr, JTI, UId);
+
+  SDValue Chain = Op.getOperand(0);
+
+  const JumpTableSDNode *JT = cast<JumpTableSDNode>(Op.getOperand(1));
+  const SDValue Index = Op.getOperand(2);
+  const DebugLoc dl = Op.getDebugLoc();
+
+
+  const SDValue UId =  DAG.getConstant(AFI->createJumpTableUId(), PTy);
+
+  const SDValue JTI = DAG.getTargetJumpTable(JT->getIndex(), PTy);
+
+  // this uses pcrel magic to materialize the table start address
+  const SDValue Table = DAG.getNode(ARMISD::WrapperJT, dl, MVT::i32, JTI, UId);
+
+  // table entries are 4 bytes, so multiple index by 4
+   const SDValue ScaledIndex = DAG.getNode(ISD::MUL, dl, PTy, Index, DAG.getConstant(4, PTy));
+
+  // add scaled index to table beginning
+  const SDValue TabEntryAddr = DAG.getNode(ISD::ADD, dl, PTy, ScaledIndex, Table);
+  SDValue JumpTarget;
+  if (isPIC) {
+     JumpTarget = DAG.getLoad((MVT)MVT::i32, dl, Chain, TabEntryAddr, NULL, 0);
+     Chain = JumpTarget.getValue(1);
+     // the table entry is not the actual target but relative to other stuff
+     // TODO: explain the exact magic here
+     JumpTarget = DAG.getNode(ISD::ADD, dl, PTy, JumpTarget, Table);
+  } else {
+    JumpTarget = DAG.getLoad(PTy, dl, Chain, TabEntryAddr, NULL, 0);
+    Chain = JumpTarget.getValue(1);
+  }
+
+  return DAG.getNode(ARMISD::BR_JT, dl, MVT::Other, Chain, JumpTarget, JTI, UId);
+}
+
+SDValue ARMTargetLowering::LowerBR_JT(SDValue Op, SelectionDAG &DAG) {
+  if (FlagOutlineJumpTables) {
+    return LowerBR_JT_Outline(Op, DAG, ++ARMJumpTableIndex, getPointerTy());
+  } else {
+    const bool isPIC = getTargetMachine().getRelocationModel() == Reloc::PIC_;
+    return LowerBR_JT_Inline(Op, DAG, isPIC, getPointerTy());
+  }
 }
 
 static SDValue LowerFP_TO_INT(SDValue Op, SelectionDAG &DAG) {
Index: lib/Target/ARM/ARMConstantPoolValue.cpp
===================================================================
--- lib/Target/ARM/ARMConstantPoolValue.cpp	(revision 72728)
+++ lib/Target/ARM/ARMConstantPoolValue.cpp	(working copy)
@@ -85,12 +85,26 @@
 }
 
 void ARMConstantPoolValue::print(raw_ostream &O) const {
+  // NOTE: this is not used for codegeneration, moreover
+  //       some of the logic is replicated in
+  //       EmitMachineConstantPoolValue()
+
   if (GV)
     O << GV->getName();
   else
     O << S;
-  if (isNonLazyPointer()) O << "$non_lazy_ptr";
-  else if (isStub()) O << "$stub";
+
+  if (isNonLazyPointer()) {
+    O << "$non_lazy_ptr";
+  } else if (isStub()) {
+    O << "$stub";
+  } else if (isDataSegmentJumpTable()) {
+    // requires synchronization with ARMAsmPrinter.cpp
+    O << "$jumptable$" << LabelId;
+  } else {
+    assert(isValue() && "unknown CP kind");
+  }
+
   if (Modifier) O << "(" << Modifier << ")";
   if (PCAdjust != 0) {
     O << "-(LPC" << LabelId << "+" << (unsigned)PCAdjust;

From isanbard at gmail.com  Tue Jun  2 18:33:52 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Tue, 2 Jun 2009 18:33:52 -0700
Subject: [LLVMdev] RFA: Alignment of Strings
Message-ID: <16e5fdf90906021833n1a4b23b1p9e5f76ed7dca1ae@mail.gmail.com>

One of our developers pointed out that GCC generates something akin to
this on Darwin:

$ cat t.c
__private_extern__ void bar(const char *format, ...)
  __attribute__ ((format (printf, 1, 2)));

void foo(const char *i, const char *b) {
  bar("this is some error message that is kind of longish.");
}

$ gcc -arch i386 -S -o - t.c -Os
	.cstring
	.align 2
LC0:
    	.ascii "this is some error message that is kind of longish.\0"
...

LLVM on the other hand generates this on Darwin:

$ /Developer/usr/bin/llvm-gcc -arch i386 -S -o - t.c -Os
...
        .section __TEXT,__cstring,cstring_literals
        .align  4
LC:
        .asciz  "this is some error message that is kind of longish."

Note that the alignment in LLVM is greater than it is for GCC. When I
look at the alignment of the string in GDB, the front-end is saying
that it's 8, which would be '.align 3'. I have a patch below that sets
the alignment explicitly for STRING_CST types.

My question is two-fold:

* Is the patch good? I don't *think* that it will break anything else
in the front-end or for different platforms, but one never knows, and,

* What magick is GCC performing to get the '.align 2' instead of
'.align 3', which I would expect? Is this something we can/should
replicate in LLVM?

-bw

Index: llvm-gcc.src/gcc/llvm-convert.cpp
===================================================================
--- llvm-gcc.src/gcc/llvm-convert.cpp	(revision 72733)
+++ llvm-gcc.src/gcc/llvm-convert.cpp	(working copy)
@@ -7418,6 +7418,8 @@
                                            TAI ?
                                             TAI->getStringConstantPrefix() :
                                             ".str", TheModule);
+  GV->setAlignment(TYPE_ALIGN(TREE_TYPE(exp)));
+
   if (SlotP) *SlotP = GV;
 #ifdef LLVM_CSTRING_SECTION
   // For Darwin, try to put it into the .cstring section.


From eli.friedman at gmail.com  Tue Jun  2 18:40:28 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Tue, 2 Jun 2009 18:40:28 -0700
Subject: [LLVMdev] patch for llc/ARM: added mechanism to move switch
	tables from .text -> .data; also cleanup and documentation
In-Reply-To: <8e3491100906021826p4530f341xbb168d260c21342e@mail.gmail.com>
References: <8e3491100906021826p4530f341xbb168d260c21342e@mail.gmail.com>
Message-ID: <f5aa3e9b0906021840t3b42597cq276f04beb343fd73@mail.gmail.com>

On Tue, Jun 2, 2009 at 6:26 PM, robert muth<robert at muth.org> wrote:
> This is my first patch submission. Hopefully, this is the proper the protocol.

This is fine, although it's usually better to submit patches to llvm-commits.

> Added mechanism to generate switch table in a data section
> rather than having it interleaved with the code.
> This is controlled by command line flags and off by default.

When would you want the flag on?  When would you want the flag off?

-Eli


From baldrick at free.fr  Tue Jun  2 23:50:05 2009
From: baldrick at free.fr (Duncan Sands)
Date: Wed, 03 Jun 2009 08:50:05 +0200
Subject: [LLVMdev] RFA: Alignment of Strings
In-Reply-To: <16e5fdf90906021833n1a4b23b1p9e5f76ed7dca1ae@mail.gmail.com>
References: <16e5fdf90906021833n1a4b23b1p9e5f76ed7dca1ae@mail.gmail.com>
Message-ID: <4A261D1D.7030909@free.fr>

Hi Bill,

> Index: llvm-gcc.src/gcc/llvm-convert.cpp
> ===================================================================
> --- llvm-gcc.src/gcc/llvm-convert.cpp	(revision 72733)
> +++ llvm-gcc.src/gcc/llvm-convert.cpp	(working copy)
> @@ -7418,6 +7418,8 @@
>                                             TAI ?
>                                              TAI->getStringConstantPrefix() :
>                                              ".str", TheModule);
> +  GV->setAlignment(TYPE_ALIGN(TREE_TYPE(exp)));

the gcc alignment is in bits, so you need to divide by 8.

Ciao,

Duncan.


From dberlin at dberlin.org  Tue Jun  2 23:52:55 2009
From: dberlin at dberlin.org (Daniel Berlin)
Date: Wed, 3 Jun 2009 02:52:55 -0400
Subject: [LLVMdev] LLVM Wiki images
In-Reply-To: <A7F555347BF740EDBA4D2010D18491D8@HPLAPTOP>
References: <A7F555347BF740EDBA4D2010D18491D8@HPLAPTOP>
Message-ID: <4aca3dc20906022352maa3e0f4n58353b2da9627432@mail.gmail.com>

I'll take care of this, sorry about thta!

On Sun, May 31, 2009 at 6:38 AM, Aaron Gray
<aaronngray.lists at googlemail.com> wrote:
> Hi,
>
> Is it possible to enable images and uploading of images on the LLVM Wiki,
> please.
>
> Thanks,
>
> Aaron
>
> _______________________________________________
> 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  Tue Jun  2 23:55:49 2009
From: baldrick at free.fr (Duncan Sands)
Date: Wed, 03 Jun 2009 08:55:49 +0200
Subject: [LLVMdev] LLVM-gcc for Ada
In-Reply-To: <4A251D57.9070602@dcc.ufmg.br>
References: <4A24D1BD.2070900@brouhaha.com> <4A24E8D3.10105@free.fr>
	<4A251D57.9070602@dcc.ufmg.br>
Message-ID: <4A261E75.6030400@free.fr>

Hi Andre,

> I created a little guide in case someone gets the same trouble as mine. 
> So here you are the link 
> http://homepages.dcc.ufmg.br/~andrelct/blog/howto/install_llvm-gcc_with_ada_support 

there is no need for the
  export CC=
  export CXX=
bits.  You can just do the export PATH= before configuring.

Ciao,

Duncan.


From baldrick at free.fr  Wed Jun  3 00:00:28 2009
From: baldrick at free.fr (Duncan Sands)
Date: Wed, 03 Jun 2009 09:00:28 +0200
Subject: [LLVMdev] LLVM-gcc for Ada
In-Reply-To: <4A25C7B4.5000600@brouhaha.com>
References: <4A25C7B4.5000600@brouhaha.com>
Message-ID: <4A261F8C.4060707@free.fr>

Hi Eric,

> llvm-main.o: In function `__static_initialization_and_destruction_0':
> /usr/lib/gcc/i386-redhat-linux/4.3.2/../../../../include/c++/4.3.2/iostream:77: 
> undefi\
> ned reference to `std::ios_base::Init::Init()'
> /usr/lib/gcc/i386-redhat-linux/4.3.2/../../../../include/c++/4.3.2/iostream:77: 
> undefi\
> ned reference to `std::ios_base::Init::~Init()'
> llvm-main.o:(.eh_frame+0x11): undefined reference to `__gxx_personality_v0'

there's something very wrong with your C++ compiler.  Rather than
exporting CC and CXX like in Andre's instructions, I suggest you
just export the PATH like in Andre's instructions before configuring/
make.  Also, are you aware of this page:
   http://llvm.org/docs/GCCFEBuildInstrs.html
?


Ciao,

Duncan.


From sanjiv.gupta at microchip.com  Wed Jun  3 01:27:21 2009
From: sanjiv.gupta at microchip.com (Sanjiv Gupta)
Date: Wed, 03 Jun 2009 13:57:21 +0530
Subject: [LLVMdev] llvmc for PIC16
Message-ID: <4A2633E9.4070207@microchip.com>

PIC16 now has clang and llc based system to generate native assembly. We 
then use our native assembler (gpasm) and the native linker (mplink) to 
generate the final executable.  How can I integrate these things with 
the driver llvmc to have gcc like user experience?  Note that we also 
want to run llvm-ld in order to perform the LTOs in case of multiple files.

- Sanjiv


From jay.foad at gmail.com  Wed Jun  3 02:50:44 2009
From: jay.foad at gmail.com (Jay Foad)
Date: Wed, 3 Jun 2009 10:50:44 +0100
Subject: [LLVMdev] invoke semantics
In-Reply-To: <1CBFF033-0CFC-4565-8862-06C6EEC7C306@apple.com>
References: <200905221647.n4MGlBHZ002297@zion.cs.uiuc.edu>
	<D63B65AE-320B-4FB9-B28F-1CDF80AA255C@apple.com>
	<7F6763FB-77F1-4356-A22D-7A00B3BFF2FF@apple.com>
	<ee2e06e90905221202o67f13893m126a0ff094d51982@mail.gmail.com>
	<1CBFF033-0CFC-4565-8862-06C6EEC7C306@apple.com>
Message-ID: <ee2e06e90906030250h78c7cecfp8770523c5123c861@mail.gmail.com>

>> No. If the invoked function unwinds then it doesn't return a value.
>> I'm pretty sure that -verify will reject your testcase.
>
> Thanks to you and others for answering this. I've added a sentence to
> LangRef.html making this explicit.

I've had a go at documenting a bit more rigorously how phi and invoke
instructions affect the SSA form. Patch attached.

> Though, opt -verify does not currently reject the testcase I posted.

Is it OK to commit my changes to LangRef.html and then raise bugs
against -verify if it doesn't do what I said? :-)

Thanks,
Jay.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.phiinvoke
Type: application/octet-stream
Size: 1270 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090603/82d7c923/attachment.obj>

From eli.friedman at gmail.com  Wed Jun  3 03:02:37 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Wed, 3 Jun 2009 03:02:37 -0700
Subject: [LLVMdev] invoke semantics
In-Reply-To: <ee2e06e90906030250h78c7cecfp8770523c5123c861@mail.gmail.com>
References: <200905221647.n4MGlBHZ002297@zion.cs.uiuc.edu>
	<D63B65AE-320B-4FB9-B28F-1CDF80AA255C@apple.com>
	<7F6763FB-77F1-4356-A22D-7A00B3BFF2FF@apple.com>
	<ee2e06e90905221202o67f13893m126a0ff094d51982@mail.gmail.com>
	<1CBFF033-0CFC-4565-8862-06C6EEC7C306@apple.com>
	<ee2e06e90906030250h78c7cecfp8770523c5123c861@mail.gmail.com>
Message-ID: <f5aa3e9b0906030302n69273221qaee4220d69ff093@mail.gmail.com>

On Wed, Jun 3, 2009 at 2:50 AM, Jay Foad<jay.foad at gmail.com> wrote:
>> Though, opt -verify does not currently reject the testcase I posted.
>
> Is it OK to commit my changes to LangRef.html and then raise bugs
> against -verify if it doesn't do what I said? :-)

Looks fine.  I think -verify got fixed recently to do the right thing here.

-Eli


From baldrick at free.fr  Wed Jun  3 03:30:21 2009
From: baldrick at free.fr (Duncan Sands)
Date: Wed, 03 Jun 2009 12:30:21 +0200
Subject: [LLVMdev] invoke semantics
In-Reply-To: <ee2e06e90906030250h78c7cecfp8770523c5123c861@mail.gmail.com>
References: <200905221647.n4MGlBHZ002297@zion.cs.uiuc.edu>	<D63B65AE-320B-4FB9-B28F-1CDF80AA255C@apple.com>	<7F6763FB-77F1-4356-A22D-7A00B3BFF2FF@apple.com>	<ee2e06e90905221202o67f13893m126a0ff094d51982@mail.gmail.com>	<1CBFF033-0CFC-4565-8862-06C6EEC7C306@apple.com>
	<ee2e06e90906030250h78c7cecfp8770523c5123c861@mail.gmail.com>
Message-ID: <4A2650BD.8090909@free.fr>

> Is it OK to commit my changes to LangRef.html and then raise bugs
> against -verify if it doesn't do what I said? :-)

Please do.  I beefed up the verifier, but maybe I missed something.

Ciao,

Duncan.


From jay.foad at gmail.com  Wed Jun  3 03:33:06 2009
From: jay.foad at gmail.com (Jay Foad)
Date: Wed, 3 Jun 2009 11:33:06 +0100
Subject: [LLVMdev] debug info for global variables when optimising
In-Reply-To: <C7C054D5-842B-4B57-95C4-98DA9B5AB968@apple.com>
References: <ee2e06e90905290624r743a03bdwa193bd64233ed23@mail.gmail.com>
	<C7C054D5-842B-4B57-95C4-98DA9B5AB968@apple.com>
Message-ID: <ee2e06e90906030333n7867d15eo9e98de4eb86836fd@mail.gmail.com>

> TEST=ipodbgopt currently runs through -strip-debug-declare immediately,
> which would hide such cases.  Try it with that flag removed and I bet you'll
> see some failures.

Yes, thanks, I hadn't noticed the -strip-debug-declare.

Incidentally I only "see" the failures because some "TEST-FAIL"
messages whizz up and off the screen. The actual "make TEST=ipodbgopt"
command completes successfully. Is that intentional?

Thanks,
Jay.



From jay.foad at gmail.com  Wed Jun  3 04:21:16 2009
From: jay.foad at gmail.com (Jay Foad)
Date: Wed, 3 Jun 2009 12:21:16 +0100
Subject: [LLVMdev] invoke semantics
In-Reply-To: <4A2650BD.8090909@free.fr>
References: <200905221647.n4MGlBHZ002297@zion.cs.uiuc.edu>
	<D63B65AE-320B-4FB9-B28F-1CDF80AA255C@apple.com>
	<7F6763FB-77F1-4356-A22D-7A00B3BFF2FF@apple.com>
	<ee2e06e90905221202o67f13893m126a0ff094d51982@mail.gmail.com>
	<1CBFF033-0CFC-4565-8862-06C6EEC7C306@apple.com>
	<ee2e06e90906030250h78c7cecfp8770523c5123c861@mail.gmail.com>
	<4A2650BD.8090909@free.fr>
Message-ID: <ee2e06e90906030421y64000ef3n99a4275b9eaaab18@mail.gmail.com>

>> Is it OK to commit my changes to LangRef.html and then raise bugs
>> against -verify if it doesn't do what I said? :-)
>
> Please do.  I beefed up the verifier, but maybe I missed something.

Looks pretty bomb-proof to me. Thanks for fixing it!

Thanks,
Jay.



From aaronngray.lists at googlemail.com  Wed Jun  3 07:17:57 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Wed, 3 Jun 2009 15:17:57 +0100
Subject: [LLVMdev] LLVM Wiki images
In-Reply-To: <4aca3dc20906022352maa3e0f4n58353b2da9627432@mail.gmail.com>
References: <A7F555347BF740EDBA4D2010D18491D8@HPLAPTOP>
	<4aca3dc20906022352maa3e0f4n58353b2da9627432@mail.gmail.com>
Message-ID: <9719867c0906030717v28346f59i8524814c3856c897@mail.gmail.com>

2009/6/3 Daniel Berlin <dberlin at dberlin.org>

> I'll take care of this, sorry about thta!


Great, no worries.

Aaron


>
>
> On Sun, May 31, 2009 at 6:38 AM, Aaron Gray
> <aaronngray.lists at googlemail.com> wrote:
> > Hi,
> >
> > Is it possible to enable images and uploading of images on the LLVM Wiki,
> > please.
> >
> > Thanks,
> >
> > Aaron
> >
> > _______________________________________________
> > 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.llvm.org/pipermail/llvm-dev/attachments/20090603/1bf81d4d/attachment.html>

From ofv at wanadoo.es  Wed Jun  3 08:18:46 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Wed, 03 Jun 2009 17:18:46 +0200
Subject: [LLVMdev] CMake build maturity
References: <4A15158A.2010702@laposte.net> <4A15CA60.5090108@telenix.org>
	<305d6f60905211611w555ac98k76a13a05ba6549b0@mail.gmail.com>
	<4A16B53D.7080806@telenix.org>
	<31963.75942.qm@web62005.mail.re1.yahoo.com>
	<4A16C2E3.1010604@telenix.org> <874ovdt4az.fsf@telefonica.net>
	<4A1704AC.8050500@assumetheposition.nl>
	<87zld4svbr.fsf@telefonica.net>
	<4A1D1926.8010405@assumetheposition.nl>
	<87fxeqk05c.fsf@telefonica.net>
	<4A23B644.2000500@assumetheposition.nl>
	<4A23BF1D.3000004@assumetheposition.nl> <4A23D7D4.2080108@wxs.nl>
Message-ID: <87tz2xibvt.fsf@telefonica.net>

Frits van Bommel <fvbommel at wxs.nl> writes:

> Paul Melis wrote:
>> Just checked: yup, there's plenty of assert()'s in the headers, so
>> -D_DEBUG will keep those alive.
>> 
>> Interestingly, when configuring with --enable-optimized and
>> --disable-assertions the resulting compilation calls itself a
>> "Release-Asserts build" while all asserts are thrown away, hmmm :)
>
> Yeah, that's "Release-Asserts" as in "Release minus asserts".
>
> This has caused confusion before...

Committed a change for the cmake build that implements the option
LLVM_ENABLE_ASSERTS. Defaults to ON if and only if CMAKE_BUILD_TYPE is
Release.

-- 
Óscar



From dalej at apple.com  Wed Jun  3 09:52:26 2009
From: dalej at apple.com (Dale Johannesen)
Date: Wed, 3 Jun 2009 09:52:26 -0700
Subject: [LLVMdev] debug info for global variables when optimising
In-Reply-To: <ee2e06e90906030333n7867d15eo9e98de4eb86836fd@mail.gmail.com>
References: <ee2e06e90905290624r743a03bdwa193bd64233ed23@mail.gmail.com>
	<C7C054D5-842B-4B57-95C4-98DA9B5AB968@apple.com>
	<ee2e06e90906030333n7867d15eo9e98de4eb86836fd@mail.gmail.com>
Message-ID: <CF6576B1-74EF-4CC0-A41F-D9B48021B602@apple.com>


On Jun 3, 2009, at 3:33 AMPDT, Jay Foad wrote:

>> TEST=ipodbgopt currently runs through -strip-debug-declare  
>> immediately,
>> which would hide such cases.  Try it with that flag removed and I  
>> bet you'll
>> see some failures.
>
> Yes, thanks, I hadn't noticed the -strip-debug-declare.
>
> Incidentally I only "see" the failures because some "TEST-FAIL"
> messages whizz up and off the screen. The actual "make TEST=ipodbgopt"
> command completes successfully. Is that intentional?

Yes, AFAIK I'm the only one ever to use ipodbgopt, and that was  
adequate for my needs.  Feel free to enhance.



From robert at muth.org  Wed Jun  3 11:33:36 2009
From: robert at muth.org (robert muth)
Date: Wed, 3 Jun 2009 14:33:36 -0400
Subject: [LLVMdev] patch for llc/ARM: added mechanism to move switch
	tables from .text -> .data; also cleanup and documentation
In-Reply-To: <f5aa3e9b0906021840t3b42597cq276f04beb343fd73@mail.gmail.com>
References: <8e3491100906021826p4530f341xbb168d260c21342e@mail.gmail.com>
	<f5aa3e9b0906021840t3b42597cq276f04beb343fd73@mail.gmail.com>
Message-ID: <8e3491100906031133l78b945a1u5cfb33b80f3961ee@mail.gmail.com>

On Tue, Jun 2, 2009 at 9:40 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> On Tue, Jun 2, 2009 at 6:26 PM, robert muth<robert at muth.org> wrote:
>> This is my first patch submission. Hopefully, this is the proper the protocol.
>
> This is fine, although it's usually better to submit patches to llvm-commits.
>
>> Added mechanism to generate switch table in a data section
>> rather than having it interleaved with the code.
>> This is controlled by command line flags and off by default.
>
> When would you want the flag on?  When would you want the flag off?
>
> -Eli


The disadvantage of "outlining" the switch tables is the extra
constant pool load
incurred for loading the start address of the table into the register

The advantages are:
 * cleaner code both on the llvm side and the generated side
 which may be beneficial for  the ARM JIT (though I have not looked at this).
* no PIC problems in the text section as we just move the relocatable
 entries elsewhere.
 * better instruction density in the text section as jumptables can
grow quite large subsequently and may cause certain offsets to overflow
 * also AFAIK jumptables are the only "bigger than wordsize" data item in text.
 The constant pools usually just contain 32bit quantities. In a past
life this made
 it hard for me to binary rewrite arm executables.





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



From keveman at gmail.com  Wed Jun  3 12:46:41 2009
From: keveman at gmail.com (Manjunath Kudlur)
Date: Wed, 3 Jun 2009 12:46:41 -0700
Subject: [LLVMdev] Adding instructions to MachineBlock
Message-ID: <68c4c3e20906031246u61656b02h55e8c2f0a58fe743@mail.gmail.com>

Hello,

I am writing a MachineFunction pass that converts vector instructions
to a sequence of scalar instructions. First, I go through the function
and look for vector registers. For each vector register, I create a
set of corresponding scalar registers using createVirtualRegister()
function and put it in a map. Then I go through the function and
replace vector instructions.The basic structure of the code is as
follows :

  for(MachineFunction::iterator BI=F.begin(), BE=F.end(); BI!=BE; ++BI) {
    MachineBasicBlock *BB = &*BI;

    std::vector<MachineInstr *> toRemove;
    std::vector<MachineInstr *> copies;

    for(MachineBasicBlock::iterator II=BB->begin(), IE=BB->end();
II!=IE; ++II) {
      MachineInstr *Instr = &*II;

      if(!isVectorInstr(Instr))
        continue;

      copies.clear();
      createCopies(F, Instr, copies);
      for(unsigned i=0, e=copies.size(); i!=e; ++i)
        BB->insert(II, copies[i]);
    }
    for(unsigned i=0, e=toRemove.size(); i!=e; ++i)
      BB->remove(toRemove[i]);
  }

The createCopies function creates a set of instructions. Say we have a
vector instruction vx <- f(vy, vz), and say the vector sizes of
vx,vy,vz are 2, then 'copies' will contain 2 instructions
x1<-f'(y1,z1) and x2<-f'(y2,z2), where f' is the corresponding scalar
instruction. Now, when I am trying to insert the new instructions into
the basic block (BB->insert(II, copies[i])), I am seeing a segfault.
MachineOperand::AddRegOperandToRegInfo is getting called by
BB->insert() and RegInfo->getRegUseDefListHead(getReg()) for the new
register is 0xffffffff somehow. I suspect I am not following some
rules when adding the instructions to a basic block. I would be
grateful if some one can point out what I am doing wrong, and provide
suggestions on how to go about doing this.

Thanks,
Manjunath


From lhames at gmail.com  Wed Jun  3 13:34:26 2009
From: lhames at gmail.com (Lang Hames)
Date: Wed, 3 Jun 2009 13:34:26 -0700
Subject: [LLVMdev] Removing SimpleRewriter (formerly SimpleSpiller)
Message-ID: <728927c70906031334l307ba6a0l71a13b10bf7976c8@mail.gmail.com>

Hi all,

Is anyone still using SimpleRewriter (formerly known as
SimpleSpiller)? A quick check with the test suite suggests that it's
badly broken. If it's not being used I'd like to remove it as part of
my tidy-up of the register allocator.

- Lang.


From eli.friedman at gmail.com  Wed Jun  3 13:56:01 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Wed, 3 Jun 2009 13:56:01 -0700
Subject: [LLVMdev] Adding instructions to MachineBlock
In-Reply-To: <68c4c3e20906031246u61656b02h55e8c2f0a58fe743@mail.gmail.com>
References: <68c4c3e20906031246u61656b02h55e8c2f0a58fe743@mail.gmail.com>
Message-ID: <f5aa3e9b0906031356k1420f842nfcb521ebf39ae45@mail.gmail.com>

On Wed, Jun 3, 2009 at 12:46 PM, Manjunath Kudlur<keveman at gmail.com> wrote:
> Hello,
>
> I am writing a MachineFunction pass that converts vector instructions
> to a sequence of scalar instructions.

Why?  That really isn't the level you want to be doing that sort of
thing normally.  Usually, legalization turns illegal vector operations
into legal scalar operations.

-Eli


From joe at alacatialabs.com  Wed Jun  3 14:20:26 2009
From: joe at alacatialabs.com (Joe Ranieri)
Date: Wed, 3 Jun 2009 17:20:26 -0400
Subject: [LLVMdev] Structured Exception Handling (SEH) on Windows
Message-ID: <F963D117-1443-48F6-BB1D-5F74808C674A@alacatialabs.com>

Has any progress been made on structured exception handling on  
Windows? I saw a post by Duncan Sands back in September 2008, but  
haven't seen anything since. I'm trying to generate code to run on  
Windows, but would really prefer not to ship libgcc...

-- Joe Ranieri


From keveman at gmail.com  Wed Jun  3 14:34:57 2009
From: keveman at gmail.com (Manjunath Kudlur)
Date: Wed, 3 Jun 2009 14:34:57 -0700
Subject: [LLVMdev] Adding instructions to MachineBlock
In-Reply-To: <f5aa3e9b0906031356k1420f842nfcb521ebf39ae45@mail.gmail.com>
References: <68c4c3e20906031246u61656b02h55e8c2f0a58fe743@mail.gmail.com>
	<f5aa3e9b0906031356k1420f842nfcb521ebf39ae45@mail.gmail.com>
Message-ID: <68c4c3e20906031434x2d693bf5q881802c66393d033@mail.gmail.com>

You are right, there are other approaches possible. In my case, I want
to retain some vector operations. So I translated all LLVM vector
instructions to machine vector instructions. Then I am writing this
phase to selectively translate some vector instructions to scalar
counter parts. But I feel the question is independent of this issue. I
am basically trying to add a new instruction with a def to a register.
BB->insert is failing because RegInfo->getRegUseDefListHead(getReg())
returns 0xffffffff.

Manjunath

On Wed, Jun 3, 2009 at 1:56 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> On Wed, Jun 3, 2009 at 12:46 PM, Manjunath Kudlur<keveman at gmail.com> wrote:
>> Hello,
>>
>> I am writing a MachineFunction pass that converts vector instructions
>> to a sequence of scalar instructions.
>
> Why?  That really isn't the level you want to be doing that sort of
> thing normally.  Usually, legalization turns illegal vector operations
> into legal scalar operations.
>
> -Eli
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>



From eli.friedman at gmail.com  Wed Jun  3 15:50:45 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Wed, 3 Jun 2009 15:50:45 -0700
Subject: [LLVMdev] Structured Exception Handling (SEH) on Windows
In-Reply-To: <F963D117-1443-48F6-BB1D-5F74808C674A@alacatialabs.com>
References: <F963D117-1443-48F6-BB1D-5F74808C674A@alacatialabs.com>
Message-ID: <f5aa3e9b0906031550l661b6ba4l44c45af09e1a7994@mail.gmail.com>

On Wed, Jun 3, 2009 at 2:20 PM, Joe Ranieri<joe at alacatialabs.com> wrote:
> Has any progress been made on structured exception handling on
> Windows? I saw a post by Duncan Sands back in September 2008, but
> haven't seen anything since. I'm trying to generate code to run on
> Windows, but would really prefer not to ship libgcc...

I fail to see the connection between SEH support and libgcc; for C++
exceptions to work, you will need libgcc anyway.

-Eli


From keveman at gmail.com  Wed Jun  3 17:10:44 2009
From: keveman at gmail.com (Manjunath Kudlur)
Date: Wed, 3 Jun 2009 17:10:44 -0700
Subject: [LLVMdev] assertion in LeakDetector
Message-ID: <68c4c3e20906031710w50d2c5dcid514c66485ffaa21@mail.gmail.com>

I am seeing the following assertion in leak detector.

/llvm/lib/VMCore/LeakDetector.cpp:43:
void<unnamed>::LeakDetectorImpl<T>::addGarbage(const T*) [with T =
void]: Assertion `Ts.count(Cache) == 0 && "Object already in set!"'
failed.

I am creating a list of instructions using BuildMI() and adding them
to a basic block using BB->insert(). I am seeing this assertion after
some number of insertions. Am I doing something wrong?

Manjunath


From isanbard at gmail.com  Wed Jun  3 17:26:37 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Wed, 3 Jun 2009 17:26:37 -0700
Subject: [LLVMdev] assertion in LeakDetector
In-Reply-To: <68c4c3e20906031710w50d2c5dcid514c66485ffaa21@mail.gmail.com>
References: <68c4c3e20906031710w50d2c5dcid514c66485ffaa21@mail.gmail.com>
Message-ID: <16e5fdf90906031726t7feeb7cbkf49e9d0aed92ee10@mail.gmail.com>

On Wed, Jun 3, 2009 at 5:10 PM, Manjunath Kudlur <keveman at gmail.com> wrote:
> I am seeing the following assertion in leak detector.
>
> /llvm/lib/VMCore/LeakDetector.cpp:43:
> void<unnamed>::LeakDetectorImpl<T>::addGarbage(const T*) [with T =
> void]: Assertion `Ts.count(Cache) == 0 && "Object already in set!"'
> failed.
>
> I am creating a list of instructions using BuildMI() and adding them
> to a basic block using BB->insert(). I am seeing this assertion after
> some number of insertions. Am I doing something wrong?
>
Hi Manjunath,

If you are using BuildMI(), you shouldn't have to re-insert the
instruction into the machine basic block.

-bw


From keveman at gmail.com  Wed Jun  3 17:48:20 2009
From: keveman at gmail.com (Manjunath Kudlur)
Date: Wed, 3 Jun 2009 17:48:20 -0700
Subject: [LLVMdev] assertion in LeakDetector
In-Reply-To: <16e5fdf90906031726t7feeb7cbkf49e9d0aed92ee10@mail.gmail.com>
References: <68c4c3e20906031710w50d2c5dcid514c66485ffaa21@mail.gmail.com>
	<16e5fdf90906031726t7feeb7cbkf49e9d0aed92ee10@mail.gmail.com>
Message-ID: <68c4c3e20906031748y57c27c0dudc5a2a1e51216728@mail.gmail.com>

Hi Bill,

I am using the following version of BuildMI :

MachineInstrBuilder  BuildMI(MachineFunction &MF,
                                    const TargetInstrDesc &TID,
                                    unsigned DestReg)

I do the following :

void createInstrs(std::vector<MachineInstr *>& ilist)
{
  Machine Instr *mi;

  mi = BuildMI(MF, someTID, somereg);
  ilist.push_back(mi);
  mi = BuildMI(MF, someotherTID, someotherreg);
  ilist.push_back(mi);
}

viud insertInto(MachineBasicBlock *BB, MachineBasicBlock::iterator II)
{
   std::vector<MachineInstr *> temp;
   createInstrs(temp);

   for(unsigned i=0, e=temp.size(); i!=e; ++i)
     BB->insert(II, temp[i]);
}

I am getting the assertion during BB->insert()

Manjunath
On Wed, Jun 3, 2009 at 5:26 PM, Bill Wendling <isanbard at gmail.com> wrote:
> On Wed, Jun 3, 2009 at 5:10 PM, Manjunath Kudlur <keveman at gmail.com> wrote:
>> I am seeing the following assertion in leak detector.
>>
>> /llvm/lib/VMCore/LeakDetector.cpp:43:
>> void<unnamed>::LeakDetectorImpl<T>::addGarbage(const T*) [with T =
>> void]: Assertion `Ts.count(Cache) == 0 && "Object already in set!"'
>> failed.
>>
>> I am creating a list of instructions using BuildMI() and adding them
>> to a basic block using BB->insert(). I am seeing this assertion after
>> some number of insertions. Am I doing something wrong?
>>
> Hi Manjunath,
>
> If you are using BuildMI(), you shouldn't have to re-insert the
> instruction into the machine basic block.
>
> -bw
> _______________________________________________
> 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  Wed Jun  3 17:51:12 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Wed, 3 Jun 2009 17:51:12 -0700
Subject: [LLVMdev] Removing SimpleRewriter (formerly SimpleSpiller)
In-Reply-To: <728927c70906031334l307ba6a0l71a13b10bf7976c8@mail.gmail.com>
References: <728927c70906031334l307ba6a0l71a13b10bf7976c8@mail.gmail.com>
Message-ID: <98BC26EF-5A97-4425-AA7A-4D2D0E11CCC5@apple.com>

I vote for execution of SimpleRewriter.

Evan

On Jun 3, 2009, at 1:34 PM, Lang Hames wrote:

> Hi all,
>
> Is anyone still using SimpleRewriter (formerly known as
> SimpleSpiller)? A quick check with the test suite suggests that it's
> badly broken. If it's not being used I'd like to remove it as part of
> my tidy-up of the register allocator.
>
> - Lang.
> _______________________________________________
> 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  Wed Jun  3 17:53:28 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Wed, 3 Jun 2009 17:53:28 -0700
Subject: [LLVMdev] patch for llc/ARM: added mechanism to move switch
	tables from .text -> .data; also cleanup and documentation
In-Reply-To: <8e3491100906021826p4530f341xbb168d260c21342e@mail.gmail.com>
References: <8e3491100906021826p4530f341xbb168d260c21342e@mail.gmail.com>
Message-ID: <C4EFBD7C-9D40-4D63-8DC1-C8B656170B81@apple.com>

I will have a look at this in a couple of days...

Evan
On Jun 2, 2009, at 6:26 PM, robert muth wrote:

> Hi:
>
> This is my first patch submission. Hopefully, this is the proper the  
> protocol.
> Attached is a patch for the llc ARM backend:
>
> Added mechanism to generate switch table in a data section
> rather than having it interleaved with the code.
> This is controlled by command line flags and off by default.
> Also, tried to document and improve the code where I modified it.
>
> Robert
> <llc.patch.txt>_______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



From isanbard at gmail.com  Wed Jun  3 18:03:47 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Wed, 3 Jun 2009 18:03:47 -0700
Subject: [LLVMdev] assertion in LeakDetector
In-Reply-To: <68c4c3e20906031748y57c27c0dudc5a2a1e51216728@mail.gmail.com>
References: <68c4c3e20906031710w50d2c5dcid514c66485ffaa21@mail.gmail.com>
	<16e5fdf90906031726t7feeb7cbkf49e9d0aed92ee10@mail.gmail.com>
	<68c4c3e20906031748y57c27c0dudc5a2a1e51216728@mail.gmail.com>
Message-ID: <16e5fdf90906031803h71fe7b52teb9e9b5d626f6278@mail.gmail.com>

On Wed, Jun 3, 2009 at 5:48 PM, Manjunath Kudlur <keveman at gmail.com> wrote:
> Hi Bill,
>
> I am using the following version of BuildMI :
>
> MachineInstrBuilder  BuildMI(MachineFunction &MF,
>                                    const TargetInstrDesc &TID,
>                                    unsigned DestReg)
>
> I do the following :
>
> void createInstrs(std::vector<MachineInstr *>& ilist)
> {
>  Machine Instr *mi;
>
>  mi = BuildMI(MF, someTID, somereg);
>  ilist.push_back(mi);
>  mi = BuildMI(MF, someotherTID, someotherreg);
>  ilist.push_back(mi);
> }
>
> viud insertInto(MachineBasicBlock *BB, MachineBasicBlock::iterator II)
> {
>   std::vector<MachineInstr *> temp;
>   createInstrs(temp);
>
>   for(unsigned i=0, e=temp.size(); i!=e; ++i)
>     BB->insert(II, temp[i]);
> }
>
> I am getting the assertion during BB->insert()
>
Hi Manjunath,

Yep! It's putting them into the basic block for you. Though perhaps
not exactly where you want them to be.

You probably want to use this version of BuildMI:

/// BuildMI - This version of the builder inserts the newly-built
/// instruction before the given position in the given
MachineBasicBlock, and
/// sets up the first operand as a destination virtual register.
///
inline MachineInstrBuilder BuildMI(MachineBasicBlock &BB,
                                   MachineBasicBlock::iterator I,
                                   DebugLoc DL,
                                   const TargetInstrDesc &TID,
                                   unsigned DestReg);

in the 'createInstrs' function and *don't* run the 'for' loop to
re-insert them into the basic block.

-bw



From jrk at csail.mit.edu  Wed Jun  3 18:29:37 2009
From: jrk at csail.mit.edu (Jonathan Ragan-Kelley)
Date: Wed, 3 Jun 2009 18:29:37 -0700 (PDT)
Subject: [LLVMdev] Windows x64 JIT usability
Message-ID: <29068ee7-1341-4048-89e3-a25df8f59469@g19g2000yql.googlegroups.com>

What is the current state of the JIT on Windows x64?

I have noticed intermittent conversation about past incompatibility
due to the calling convention idiosyncrasies, as well as some
suggestion from last fall that it was targeted for a fix in the 2.5
timeframe, but see no definitive conclusion. Is this working in 2.5,
in trunk, or likely to be in trunk soon?


From eli.friedman at gmail.com  Wed Jun  3 18:36:57 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Wed, 3 Jun 2009 18:36:57 -0700
Subject: [LLVMdev] Windows x64 JIT usability
In-Reply-To: <29068ee7-1341-4048-89e3-a25df8f59469@g19g2000yql.googlegroups.com>
References: <29068ee7-1341-4048-89e3-a25df8f59469@g19g2000yql.googlegroups.com>
Message-ID: <f5aa3e9b0906031836u19b0b06cpdf07965f105c5ea9@mail.gmail.com>

On Wed, Jun 3, 2009 at 6:29 PM, Jonathan Ragan-Kelley<jrk at csail.mit.edu> wrote:
> What is the current state of the JIT on Windows x64?

Broken; at the very least, there's http://llvm.org/bugs/show_bug.cgi?id=3739 .

-Eli


From cr88192 at hotmail.com  Wed Jun  3 19:24:19 2009
From: cr88192 at hotmail.com (BGB)
Date: Wed, 3 Jun 2009 19:24:19 -0700
Subject: [LLVMdev] Windows x64 JIT usability
References: <29068ee7-1341-4048-89e3-a25df8f59469@g19g2000yql.googlegroups.com>
	<f5aa3e9b0906031836u19b0b06cpdf07965f105c5ea9@mail.gmail.com>
Message-ID: <BLU119-DAV32737606B03EBB7357D7CE44B0@phx.gbl>


----- Original Message ----- 
From: "Eli Friedman" <eli.friedman at gmail.com>
To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
Sent: Wednesday, June 03, 2009 6:36 PM
Subject: Re: [LLVMdev] Windows x64 JIT usability


> On Wed, Jun 3, 2009 at 6:29 PM, Jonathan Ragan-Kelley<jrk at csail.mit.edu> 
> wrote:
>> What is the current state of the JIT on Windows x64?
>
> Broken; at the very least, there's 
> http://llvm.org/bugs/show_bug.cgi?id=3739 .
>

sad...

in my case, otherwise I would have asked if anyone had benchmarked the 
SysV/AMD64 calling convention vs the Win64 calling convention...

I personally want to know what is faster, but can't find any benchmarks, nor 
am that inclined in going through all the steps to get it working 
(installing a 64-bit windows, geting 64-bit compilation set up, and getting 
benchmarks to compare between Windows and Linux, ...).

but, alas, if anyone has tested this, I am hoping I can hear the results...


(sadly, I don't have anything available to accurately test Win64 on a 
Linux-based setup, but this could be technically more accurate than using 
Windows, since it would reduce the risk of OS-specific overhead 
differences...).


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



From joe at alacatialabs.com  Wed Jun  3 20:57:08 2009
From: joe at alacatialabs.com (Joe Ranieri)
Date: Wed, 3 Jun 2009 23:57:08 -0400
Subject: [LLVMdev] Structured Exception Handling (SEH) on Windows
In-Reply-To: <f5aa3e9b0906031550l661b6ba4l44c45af09e1a7994@mail.gmail.com>
References: <F963D117-1443-48F6-BB1D-5F74808C674A@alacatialabs.com>
	<f5aa3e9b0906031550l661b6ba4l44c45af09e1a7994@mail.gmail.com>
Message-ID: <D848267A-DF3E-4A3F-9283-1C1C4262E909@alacatialabs.com>


On Jun 3, 2009, at 18:50, Eli Friedman wrote:

> On Wed, Jun 3, 2009 at 2:20 PM, Joe Ranieri<joe at alacatialabs.com>  
> wrote:
>> Has any progress been made on structured exception handling on
>> Windows? I saw a post by Duncan Sands back in September 2008, but
>> haven't seen anything since. I'm trying to generate code to run on
>> Windows, but would really prefer not to ship libgcc...
>
> I fail to see the connection between SEH support and libgcc; for C++
> exceptions to work, you will need libgcc anyway.

Well, I had thought that SEH was a superset of C++ exception handling,  
similar to how the unwind library is to the C++ exception handling  
with libgcc. Looking further into this, it seems not to be the case.  
What I'd like to end up with is exceptions compatible with DLLs  
generated with Visual Studio C++. I'm not much of a Windows person, so  
don't really know the best way to approach it.

However, this is a long term goal, and for now I just need an  
exception system to work inside of the code I generate with LLVM.  
Since I don't really have much time to spend on this, I think for now  
I'll implement something quick and dirty using setjmp/longjmp.

Anyone have better ideas?

-- Joe Ranieri


From clattner at apple.com  Wed Jun  3 22:46:53 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 3 Jun 2009 22:46:53 -0700
Subject: [LLVMdev] Removing SimpleRewriter (formerly SimpleSpiller)
In-Reply-To: <98BC26EF-5A97-4425-AA7A-4D2D0E11CCC5@apple.com>
References: <728927c70906031334l307ba6a0l71a13b10bf7976c8@mail.gmail.com>
	<98BC26EF-5A97-4425-AA7A-4D2D0E11CCC5@apple.com>
Message-ID: <10F73596-5E3E-49B3-8920-3E72D17F0535@apple.com>

On Jun 3, 2009, at 5:51 PM, Evan Cheng wrote:
> I vote for execution of SimpleRewriter.

Yeah, go ahead and axe it: Off with its head!

-Chris

>
>
> Evan
>
> On Jun 3, 2009, at 1:34 PM, Lang Hames wrote:
>
>> Hi all,
>>
>> Is anyone still using SimpleRewriter (formerly known as
>> SimpleSpiller)? A quick check with the test suite suggests that it's
>> badly broken. If it's not being used I'd like to remove it as part of
>> my tidy-up of the register allocator.
>>
>> - Lang.
>> _______________________________________________
>> 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 jay.foad at gmail.com  Wed Jun  3 23:03:41 2009
From: jay.foad at gmail.com (Jay Foad)
Date: Thu, 4 Jun 2009 07:03:41 +0100
Subject: [LLVMdev] CMake build maturity
In-Reply-To: <87tz2xibvt.fsf@telefonica.net>
References: <4A15158A.2010702@laposte.net> <874ovdt4az.fsf@telefonica.net>
	<4A1704AC.8050500@assumetheposition.nl>
	<87zld4svbr.fsf@telefonica.net>
	<4A1D1926.8010405@assumetheposition.nl>
	<87fxeqk05c.fsf@telefonica.net>
	<4A23B644.2000500@assumetheposition.nl>
	<4A23BF1D.3000004@assumetheposition.nl> <4A23D7D4.2080108@wxs.nl>
	<87tz2xibvt.fsf@telefonica.net>
Message-ID: <ee2e06e90906032303t6eeb262ama968cf3cca9cb17a@mail.gmail.com>

Hi,

> Committed a change for the cmake build that implements the option
> LLVM_ENABLE_ASSERTS. Defaults to ON if and only if CMAKE_BUILD_TYPE is
> Release.

Thanks! I think it might be nice to make this a bit more consistent
with Makefile.config. I'd suggest...

- use LLVM_DISABLE_ASSERTIONS instead of LLVM_ENABLE_ASSERTS
- have it default to OFF (so assertions are enabled) always
- compile with -DNDEBUG if assertions are off -- I don't think
-UNDEBUG has any effect, because NDEBUG won't have been defined in the
first place

Thanks,
Jay.


From dodohack at gmail.com  Thu Jun  4 01:14:28 2009
From: dodohack at gmail.com (dodo)
Date: Thu, 4 Jun 2009 16:14:28 +0800
Subject: [LLVMdev] endian issue of llvm-gcc and llvm backend
Message-ID: <e6010ba80906040114l4ddf47feo2888b0e51cd512e@mail.gmail.com>

Hi, all

As I'm a Chinese, be patient of my poor description below.

I compiled libgcc into llvm bitcode in both big endian and little endian.
and got 2 different version of function: _ashldi3, the following is the
fragment of this function:

little endian:
=============================================
......
target datalayout =
"e-p:32:32:32-i1:8:8-i8:8:32-i16:16:32-i32:32:32-i64:32:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64"
target triple = "nds32le-linux"

define i64 @__ashldi3(i64 %u, i32 %b) nounwind readnone {
entry:
        %0 = icmp eq i32 %b, 0          ; <i1> [#uses=1]
        br i1 %0, label %bb5, label %bb1

bb1:            ; preds = %entry
        %1 = trunc i64 %u to i32                ; <i32> [#uses=3]
        %2 = sub i32 32, %b             ; <i32> [#uses=3]
        %3 = icmp sgt i32 %2, 0         ; <i1> [#uses=1]
        br i1 %3, label %bb3, label %bb2
......
==============================================

big endian:
==============================================
......
target datalayout =
"E-p:32:32:32-i1:8:8-i8:8:32-i16:16:32-i32:32:32-i64:32:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64"
target triple = "nds32-linux"

define i64 @__ashldi3(i64 %u, i32 %b) nounwind readnone {
entry:
        %0 = icmp eq i32 %b, 0          ; <i1> [#uses=1]
        br i1 %0, label %bb5, label %bb1

bb1:            ; preds = %entry
        %sroa.store.elt = lshr i64 %u, 32               ; <i64> [#uses=1]
        %1 = trunc i64 %sroa.store.elt to i32           ; <i32> [#uses=3]
        %2 = sub i32 32, %b             ; <i32> [#uses=3]
        %3 = icmp sgt i32 %2, 0         ; <i1> [#uses=1]
        br i1 %3, label %bb3, label %bb2
......
==============================================

>From the generated IR, we could see that llvm IR is endian dependent and it
know how to get the low 32 bits of a 64 bits parameter.

While generate asm code from these 2 different IR,  I got the same asm code.
The following is the asm code which are mips like:
(NOTE: $rx indicates a 32 bits register x, #x indicates constant, subri $r3,
$r2, #32 means r3 = 32 - r2,
r0, r1 contain the first 64 bits parameter which contains %u, r2 contains
the second parameter %b)

beqz $r2,83f6 <__ashldi3+0x2a>
subri $r3,$r2,#32
blez $r3,83fa <__ashldi3+0x2e>
sll $r1,$r1,$r2
srl $r3,$r0,$r3
or $r3,$r3,$r1
sll $r1,$r0,$r2
movi $r2,#0
mov $r0,$r1
or $r1,$r3,$r2
ret $lp
ret $lp
subri $r3,$r3,#0
movi $r1,#0
sll $r3,$r0,$r3

The above asm code is tested ok in little endian, and not ok in big endian,
because it does not get paramter %u correctly, for big endian, r0, r1 in
that asm code should be exchanged  for endian  issue.

One possible reason is that I generate code for big endian and llvm-gcc
really generates big endian IR for me(from the presented IR, it did). Then I
use llc to generate asm code, llc eat the target triple and/or datalayout
from the bitcode and generates big endian asm code for me again.
The result is that:  llvm-gcc gen'ed big endian code + llc gen'ed big endian
code = little endian code, am I right?

If I want to generate correct asm code for big endian? what should I do?
I have tried to generate big endian asm code from little endian IR by giving
-march option to llc to force the target to big endian, but this seems to be
unworkable!

-- 
dodohack at ybu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090604/7f7a6d26/attachment.html>

From jay.foad at gmail.com  Thu Jun  4 01:54:02 2009
From: jay.foad at gmail.com (Jay Foad)
Date: Thu, 4 Jun 2009 09:54:02 +0100
Subject: [LLVMdev] make check hanging in hello.c?
Message-ID: <ee2e06e90906040154y119af077l7c59891e7c5cc442@mail.gmail.com>

On an ENABLE_OPTIMIZED=1 build, "make check" hangs for me here:

Running /home/foad/svn/llvm-project/llvm/trunk/test/LLVMC/llvmc.exp ...

... while running hello.c.tmp. Is anyone else seeing this? I don't
*think* I've changed anything in my local tree since the last time I
ran these tests.

Thanks,
Jay.


From ofv at wanadoo.es  Thu Jun  4 02:27:47 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Thu, 04 Jun 2009 11:27:47 +0200
Subject: [LLVMdev] CMake build maturity
References: <4A15158A.2010702@laposte.net> <874ovdt4az.fsf@telefonica.net>
	<4A1704AC.8050500@assumetheposition.nl>
	<87zld4svbr.fsf@telefonica.net>
	<4A1D1926.8010405@assumetheposition.nl>
	<87fxeqk05c.fsf@telefonica.net>
	<4A23B644.2000500@assumetheposition.nl>
	<4A23BF1D.3000004@assumetheposition.nl> <4A23D7D4.2080108@wxs.nl>
	<87tz2xibvt.fsf@telefonica.net>
	<ee2e06e90906032303t6eeb262ama968cf3cca9cb17a@mail.gmail.com>
Message-ID: <87hbywic18.fsf@telefonica.net>

Jay Foad <jay.foad at gmail.com> writes:

>> Committed a change for the cmake build that implements the option
>> LLVM_ENABLE_ASSERTS. Defaults to ON if and only if CMAKE_BUILD_TYPE is
>> Release.
>
> Thanks! I think it might be nice to make this a bit more consistent
> with Makefile.config. I'd suggest...
>
> - use LLVM_DISABLE_ASSERTIONS instead of LLVM_ENABLE_ASSERTS

Okay.

> - have it default to OFF (so assertions are enabled) always

IMHO this is wrong: if the user asks for a release build, assertions
should be turned off by default. The fact that the configure/make build
does not follow this policy caused some surprise among the LLVM
developers and users on the past. So it is the configure/make build the
one that needs to be fixed :-)

> - compile with -DNDEBUG if assertions are off --

Good catch!

> I don't think -UNDEBUG has any effect, because NDEBUG won't have been
> defined in the first place

Right. For Release builds, cmake automatically defines NDEBUG.

-- 
Óscar



From jay.foad at gmail.com  Thu Jun  4 02:43:20 2009
From: jay.foad at gmail.com (Jay Foad)
Date: Thu, 4 Jun 2009 10:43:20 +0100
Subject: [LLVMdev] CMake build maturity
In-Reply-To: <87hbywic18.fsf@telefonica.net>
References: <4A15158A.2010702@laposte.net> <87zld4svbr.fsf@telefonica.net>
	<4A1D1926.8010405@assumetheposition.nl>
	<87fxeqk05c.fsf@telefonica.net>
	<4A23B644.2000500@assumetheposition.nl>
	<4A23BF1D.3000004@assumetheposition.nl> <4A23D7D4.2080108@wxs.nl>
	<87tz2xibvt.fsf@telefonica.net>
	<ee2e06e90906032303t6eeb262ama968cf3cca9cb17a@mail.gmail.com>
	<87hbywic18.fsf@telefonica.net>
Message-ID: <ee2e06e90906040243u2f4855d1l3c405eb07fce22bd@mail.gmail.com>

>> Thanks! I think it might be nice to make this a bit more consistent
>> with Makefile.config. I'd suggest...
>>
>> - use LLVM_DISABLE_ASSERTIONS instead of LLVM_ENABLE_ASSERTS
>
> Okay.

I meant ...DISABLE... instead of ...ENABLE...!

>> I don't think -UNDEBUG has any effect, because NDEBUG won't have been
>> defined in the first place
>
> Right. For Release builds, cmake automatically defines NDEBUG.

OK, I didn't know that!

Thanks,
Jay.


From ofv at wanadoo.es  Thu Jun  4 03:05:18 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Thu, 04 Jun 2009 12:05:18 +0200
Subject: [LLVMdev] CMake build maturity
References: <4A15158A.2010702@laposte.net> <87zld4svbr.fsf@telefonica.net>
	<4A1D1926.8010405@assumetheposition.nl>
	<87fxeqk05c.fsf@telefonica.net>
	<4A23B644.2000500@assumetheposition.nl>
	<4A23BF1D.3000004@assumetheposition.nl> <4A23D7D4.2080108@wxs.nl>
	<87tz2xibvt.fsf@telefonica.net>
	<ee2e06e90906032303t6eeb262ama968cf3cca9cb17a@mail.gmail.com>
	<87hbywic18.fsf@telefonica.net>
	<ee2e06e90906040243u2f4855d1l3c405eb07fce22bd@mail.gmail.com>
Message-ID: <878wk8iaap.fsf@telefonica.net>

Jay Foad <jay.foad at gmail.com> writes:

>>> Thanks! I think it might be nice to make this a bit more consistent
>>> with Makefile.config. I'd suggest...
>>>
>>> - use LLVM_DISABLE_ASSERTIONS instead of LLVM_ENABLE_ASSERTS
>>
>> Okay.
>
> I meant ...DISABLE... instead of ...ENABLE...!

The `configure' script accepts --enable-x and --disable-x. CMake uses
-DX=ON and -DX=OFF. For consistency, I chose to follow the naming scheme
LLVM_ENABLE_X for all the switches supported by the cmake build.

[snip]

-- 
Óscar



From jay.foad at gmail.com  Thu Jun  4 03:09:47 2009
From: jay.foad at gmail.com (Jay Foad)
Date: Thu, 4 Jun 2009 11:09:47 +0100
Subject: [LLVMdev] CMake build maturity
In-Reply-To: <878wk8iaap.fsf@telefonica.net>
References: <4A15158A.2010702@laposte.net> <87fxeqk05c.fsf@telefonica.net>
	<4A23B644.2000500@assumetheposition.nl>
	<4A23BF1D.3000004@assumetheposition.nl> <4A23D7D4.2080108@wxs.nl>
	<87tz2xibvt.fsf@telefonica.net>
	<ee2e06e90906032303t6eeb262ama968cf3cca9cb17a@mail.gmail.com>
	<87hbywic18.fsf@telefonica.net>
	<ee2e06e90906040243u2f4855d1l3c405eb07fce22bd@mail.gmail.com>
	<878wk8iaap.fsf@telefonica.net>
Message-ID: <ee2e06e90906040309y572bec01p165c579543608f33@mail.gmail.com>

> The `configure' script accepts --enable-x and --disable-x. CMake uses
> -DX=ON and -DX=OFF. For consistency, I chose to follow the naming scheme
> LLVM_ENABLE_X for all the switches supported by the cmake build.

OK, thanks!

Jay.


From e0325716 at student.tuwien.ac.at  Thu Jun  4 03:17:47 2009
From: e0325716 at student.tuwien.ac.at (Andreas Neustifter)
Date: Thu, 04 Jun 2009 12:17:47 +0200
Subject: [LLVMdev] Get Analysis from PassManager
Message-ID: <4A279F4B.8050400@student.tuwien.ac.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I try to write a tool that uses the PassManager to load profiling
information for a module like this:

	...
	ModulePass *LoaderPass = createProfileLoaderPass();
	PassMgr.add(LoaderPass);
	PassMgr.run(*M);
	...

I can verify that the pass was run, but how to I get to the ProfileInfo
implemented by that pass?

I tried

	...
	ProfileInfo PI = LoaderPass->getAnalysis<ProfileInfo>();
	...

but this does not seem to return the correct profiling information.

Thanks, Andi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkonn0sACgkQPiYq0rq7s/AqawCgjwS5F8z33kjO/cFuDc/CcBeC
d+UAn2ZXnqTCOAVO0Ib1Qu/QvEDO7wmG
=0cmm
-----END PGP SIGNATURE-----


From samuraileumas at yahoo.com  Thu Jun  4 05:22:07 2009
From: samuraileumas at yahoo.com (Samuel Crow)
Date: Thu, 4 Jun 2009 05:22:07 -0700 (PDT)
Subject: [LLVMdev] endian issue of llvm-gcc and llvm backend
In-Reply-To: <e6010ba80906040114l4ddf47feo2888b0e51cd512e@mail.gmail.com>
References: <e6010ba80906040114l4ddf47feo2888b0e51cd512e@mail.gmail.com>
Message-ID: <157221.53893.qm@web62002.mail.re1.yahoo.com>


Hello,

According to the frequently asked questions on the LLVM webpage, C++ and C cannot currently be used for platform indedpendent usage.  Your discovery doesn't fall on one of the often discovered problems though so it may be a bug in the ARM backend.  The ARM backend is considered to be experimental at this point so it is likely to have incorrect code in it.

I hope I answered your question well enough,

--Sam
________________________________
From: dodo <dodohack at gmail.com>
To: llvmdev at cs.uiuc.edu
Sent: Thursday, June 4, 2009 3:14:28 AM
Subject: [LLVMdev] endian issue of llvm-gcc and llvm backend

Hi, all

As I'm a Chinese, be patient of my poor description below.

I compiled libgcc into llvm bitcode in both big endian and little endian. and got 2 different version of function: _ashldi3, the following is the fragment of this function:

little endian:
=============================================
......
target datalayout = "e-p:32:32:32-i1:8:8-i8:8:32-i16:16:32-i32:32:32-i64:32:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64"
target triple = "nds32le-linux"

define i64 @__ashldi3(i64 %u, i32 %b) nounwind readnone {
entry:
        %0 = icmp eq i32 %b, 0          ; <i1> [#uses=1]
        br i1 %0, label %bb5, label %bb1

bb1:            ; preds = %entry
        %1 = trunc i64 %u to i32                ; <i32> [#uses=3]
        %2 = sub i32 32, %b             ; <i32> [#uses=3]
        %3 = icmp sgt i32 %2, 0         ; <i1> [#uses=1]
        br i1 %3, label %bb3, label %bb2
......
==============================================

big endian:
==============================================
......
target datalayout = "E-p:32:32:32-i1:8:8-i8:8:32-i16:16:32-i32:32:32-i64:32:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64"
target triple = "nds32-linux"

define i64 @__ashldi3(i64 %u, i32 %b) nounwind readnone {
entry:
        %0 = icmp eq i32 %b, 0          ; <i1> [#uses=1]
        br i1 %0, label %bb5, label %bb1

bb1:            ; preds = %entry
        %sroa.store.elt = lshr i64 %u, 32               ; <i64> [#uses=1]
        %1 = trunc i64 %sroa.store.elt to i32           ; <i32> [#uses=3]
        %2 = sub i32 32, %b             ; <i32> [#uses=3]
        %3 = icmp sgt i32 %2, 0         ; <i1> [#uses=1]
        br i1 %3, label %bb3, label %bb2
......
==============================================

>From the generated IR, we could see that llvm IR is endian dependent and it know how to get the low 32 bits of a 64 bits parameter.

While generate asm code from these 2 different IR,  I got the same asm code.
The following is the asm code which are mips like:
(NOTE: $rx indicates a 32 bits register x, #x indicates constant, subri $r3, $r2, #32 means r3 = 32 - r2,
r0, r1 contain the first 64 bits parameter which contains %u, r2 contains the second parameter %b)

beqz $r2,83f6 <__ashldi3+0x2a>
subri $r3,$r2,#32
blez $r3,83fa <__ashldi3+0x2e>
sll $r1,$r1,$r2
srl $r3,$r0,$r3
or $r3,$r3,$r1
sll $r1,$r0,$r2
movi $r2,#0
mov $r0,$r1
or $r1,$r3,$r2
ret $lp
ret $lp
subri $r3,$r3,#0
movi $r1,#0
sll $r3,$r0,$r3

The above asm code is tested ok in little endian, and not ok in big endian, because it does not get paramter %u correctly, for big endian, r0, r1 in  that asm code should be exchanged  for endian  issue. 

One possible reason is that I generate code for big endian and llvm-gcc really generates big endian IR for me(from the presented IR, it did). Then I use llc to generate asm code, llc eat the target triple and/or datalayout from the bitcode and generates big endian asm code for me again. 
The result is that:  llvm-gcc gen'ed big endian code + llc gen'ed big endian code = little endian code, am I right?

If I want to generate correct asm code for big endian? what should I do?
I have tried to generate big endian asm code from little endian IR by giving -march option to llc to force the target to big endian, but this seems to be unworkable!

-- 
dodohack at ybu



      


From andrelct at dcc.ufmg.br  Thu Jun  4 06:15:35 2009
From: andrelct at dcc.ufmg.br (Andre Tavares)
Date: Thu, 04 Jun 2009 10:15:35 -0300
Subject: [LLVMdev] LLVM-gcc for Ada
In-Reply-To: <4A261F8C.4060707@free.fr>
References: <4A25C7B4.5000600@brouhaha.com> <4A261F8C.4060707@free.fr>
Message-ID: <4A27C8F7.6020003@dcc.ufmg.br>

Duncan Sands wrote:
> Hi Eric,
>
>   
>> llvm-main.o: In function `__static_initialization_and_destruction_0':
>> /usr/lib/gcc/i386-redhat-linux/4.3.2/../../../../include/c++/4.3.2/iostream:77: 
>> undefi\
>> ned reference to `std::ios_base::Init::Init()'
>> /usr/lib/gcc/i386-redhat-linux/4.3.2/../../../../include/c++/4.3.2/iostream:77: 
>> undefi\
>> ned reference to `std::ios_base::Init::~Init()'
>> llvm-main.o:(.eh_frame+0x11): undefined reference to `__gxx_personality_v0'
>>     
>
> there's something very wrong with your C++ compiler.  Rather than
> exporting CC and CXX like in Andre's instructions, I suggest you
> just export the PATH like in Andre's instructions before configuring/
> make.  Also, are you aware of this page:
>    http://llvm.org/docs/GCCFEBuildInstrs.html
> ?
>
>
> Ciao,
>
> Duncan.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>   
Duncan,

in my case, and probably his also, the instruction "CXX=" is necessary, 
because g++ is broken and only g++-4.3 is working. So even if I put the 
correct path it would never choose g++-4.3 over g++. The only choice is 
to use "CXX=" to select g++-4.3 directly.

-- 
Andre Tavares
Master Student in Computer Science - UFMG - Brasil
http://dcc.ufmg.br/~andrelct



From manoel at fonetica.com.br  Thu Jun  4 06:39:24 2009
From: manoel at fonetica.com.br (=?ISO-8859-1?Q?Manoel=20Teixeira?=)
Date: Thu,  4 Jun 2009 10:39:24 -0300
Subject: [LLVMdev] Structure Alignment
In-Reply-To: <mailman.372.1244121350.22634.llvmdev@cs.uiuc.edu>
References: <mailman.372.1244121350.22634.llvmdev@cs.uiuc.edu>
Message-ID: <20090604133924.4200.qmail@hm885.locaweb.com.br>

Hi,
I have a problem using structs, when calling a function written in C from
a LLVM function or calling a LLVM function from a C one.
I noticed that the LLVM align double with 4 bytes and our run time routines
use 8, in MS Windows.
If a use #pragma pack(4) in my C programs, the routines run fine, but
I must ensure that all external call should use the #pragma directive.

If I change the llvm layout f64:64:64, the LLVM calls C functions and
the struct is OK, in the C side, but the getelemntptr fails in LLVM side.
Is there on way to ensure that the LLVM reads the correct memory position
in this case?

//#pragma pack(4)
struct xfirstStru
{
    int                var1;
    double            var2;
    int                var3;
    char    *var4;
};
typedef struct xfirstStru osX ;
typedef struct xfirstStru* PosX ;
//#pragma pack()
//
extern "C" int testOSX(    PosX osx    )
{
    printf("\nChamada C %d %f %d %s",++osx->var1,++osx->var2,++osx->var3,osx->var4);
    return 999;
}

it was
... f64:32:64 ...
and I changed it to
... f64:64:64 ...

%struct.VAR1. = getelementptr %FIRSTSTRU.* %OUTRASTRU., i32 0, i32 0        ; <i32*> [#uses=2]    %loadX = load i32* %struct.el.VAR1., align 4        ; <i32> [#uses=1]
here the first element is OK
...
%struct.el.VAR2. = getelementptr %FIRSTSTRU.* %OUTRASTRU., i32 0, i32 1        ; <i32*> [#uses=2]    %loadX = load double* %struct.el.VAR2., align 8        ; <double> [#uses=1]
here, the second is wrong
...


Thanks,
Manoel Teixeira




From andrelct at dcc.ufmg.br  Thu Jun  4 06:47:36 2009
From: andrelct at dcc.ufmg.br (Andre Tavares)
Date: Thu, 04 Jun 2009 10:47:36 -0300
Subject: [LLVMdev] SSI and ABCD for LLVM
Message-ID: <4A27D078.807@dcc.ufmg.br>

Dear Community,

I'm working on a project for Google Summer of Code, to implement the 
ABCD and Bitwidth analysis in LLVM. I'm not going to extend the 
description of the project here, this link shows my proposal 
http://homepages.dcc.ufmg.br/~andrelct/projects/gsoc_2009/proposal.

I have been in some discussions on this list about Ada and SSI that 
helped on my decisions up to this moment.

This project is due to August, and during this period I will be posting 
my progress in a blog. If someone has interest in following my progress 
I welcome you to read the blog, and I would really appreciate any 
suggestion, critics and opinions on any aspect. I understand that every 
opinion is helpful. So the blog link is 
http://gsoc2009-andrelct.blogspot.com/.

Best Regards,

-- 
Andre Tavares
Master Student in Computer Science - UFMG - Brasil
http://dcc.ufmg.br/~andrelct



From foldr at codedgers.com  Thu Jun  4 07:38:22 2009
From: foldr at codedgers.com (Mikhail Glushenkov)
Date: Thu, 4 Jun 2009 14:38:22 +0000 (UTC)
Subject: [LLVMdev] llvmc for PIC16
References: <4A2633E9.4070207@microchip.com>
Message-ID: <loom.20090604T142600-116@post.gmane.org>

Hi Sanjiv,

Sanjiv Gupta <sanjiv.gupta <at> microchip.com> writes:

> 
> PIC16 now has clang and llc based system to generate native assembly. We 
> then use our native assembler (gpasm) and the native linker (mplink) to 
> generate the final executable.  How can I integrate these things with 
> the driver llvmc to have gcc like user experience?  Note that we also 
> want to run llvm-ld in order to perform the LTOs in case of multiple files.
> 
> - Sanjiv
> 

You can start with writing a separate llvmc-based driver, say, llvmc-pic16, that
uses your custom toolchain. The documentation and examples (especially
examples/Skeleton) should get you started. Once you get this working, I can
integrate your changes into mainline llvmc.

I'll be happy to answer any further questions you may have, feel free to e-mail
me directly (though right now our mail server is down).



From kevinn.tian at gmail.com  Thu Jun  4 08:10:03 2009
From: kevinn.tian at gmail.com (Kelvin Tian)
Date: Thu, 4 Jun 2009 11:10:03 -0400
Subject: [LLVMdev] LLVM build error under gcc version 4.2.1 (SUSE Linux)
Message-ID: <9846fcd40906040810n39e2bf8kbdf811503c39496e@mail.gmail.com>

Hi,

     I tried to install LLVM under gcc version 4.2.1 (SUSE Linux). And
here's the strange error I got when I tried to build llvm using gmake. Has
anyone else met with similar error under same platform? Thanks a lot.

.....
.....
`.gnu.linkonce.t._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3MVTE'
referenced in section
`.gnu.linkonce.r._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3MVTE' of
/home/ktian/llvm/llvm-2.5/Release/lib/libLLVMSelectionDAG.a(LegalizeVectorTypes.o):
defined in discarded section
`.gnu.linkonce.t._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3MVTE' of
/home/ktian/llvm/llvm-2.5/Release/lib/libLLVMSelectionDAG.a(LegalizeVectorTypes.o)
`.gnu.linkonce.t._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3MVTE'
referenced in section
`.gnu.linkonce.r._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3MVTE' of
/home/ktian/llvm/llvm-2.5/Release/lib/libLLVMSelectionDAG.a(LegalizeVectorTypes.o):
defined in discarded section
`.gnu.linkonce.t._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3MVTE' of
/home/ktian/llvm/llvm-2.5/Release/lib/libLLVMSelectionDAG.a(LegalizeVectorTypes.o)
collect2: ld returned 1 exit status
gmake[2]: *** [/home/ktian/llvm/llvm-2.5/Release/examples/ParallelJIT] Error
1
gmake[2]: Target `all' not remade because of errors.
gmake[2]: Leaving directory `/home/ktian/llvm/llvm-2.5/examples/ParallelJIT'
gmake[1]: *** [ParallelJIT/.makeall] Error 2
gmake[1]: Target `all' not remade because of errors.
gmake[1]: Leaving directory `/home/ktian/llvm/llvm-2.5/examples'
gmake: *** [all] Error 1
llvm[0]: ***** Completed Release Build



--
Best regards,
Kelvin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090604/fb2fb862/attachment.html>

From e0325716 at student.tuwien.ac.at  Thu Jun  4 08:18:45 2009
From: e0325716 at student.tuwien.ac.at (Andreas Neustifter)
Date: Thu, 04 Jun 2009 17:18:45 +0200
Subject: [LLVMdev] Get Analysis from PassManager
In-Reply-To: <4A279F4B.8050400@student.tuwien.ac.at>
References: <4A279F4B.8050400@student.tuwien.ac.at>
Message-ID: <4A27E5D5.3010702@student.tuwien.ac.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Okay, found it:

Andreas Neustifter wrote:
> I try to write a tool that uses the PassManager to load profiling
> information for a module like this:
> 
> 	...
> 	ModulePass *LoaderPass = createProfileLoaderPass();
> 	PassMgr.add(LoaderPass);
> 	PassMgr.run(*M);
> 	...
> 
> I can verify that the pass was run, but how to I get to the ProfileInfo
> implemented by that pass?
> 
> I tried
> 
> 	...
> 	ProfileInfo PI = LoaderPass->getAnalysis<ProfileInfo>();
> 	...
> 
> but this does not seem to return the correct profiling information.

I have writen a small pass that just does what I need:

namespace {
  class LoaderInterface : public ModulePass {
    ProfileInfo *PI;
  public:
    static char ID; // Class identification, replacement for typeinfo
    explicit LoaderInterface() : ModulePass(&ID) {}

    virtual void getAnalysisUsage(AnalysisUsage &AU) const {
      AU.setPreservesAll();
      AU.addRequired<ProfileInfo>();
    }

    ProfileInfo* getPI() {
      return PI;
    }

    bool runOnModule(Module &M) {
      PI = &getAnalysis<ProfileInfo>();
      return false;
    }
  };
}

char LoaderInterface::ID = 0;

So now I can just use the pass as expected:

    ....
    PassManager PassMgr = PassManager();
    PassMgr.add(createProfileLoaderPass());
    LoaderInterface *LI = new LoaderInterface();
    PassMgr.add(LI);
    PassMgr.run(*M);
    ProfileInfo *PI = LI->getPI();
    ....

Andi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkon5dUACgkQPiYq0rq7s/BB/gCfQEaRL5ZrAralWrYFnnkO7heU
v6kAnR+HLruRNj/IGoTh8ud//U1xHBMc
=jC9S
-----END PGP SIGNATURE-----


From nicolas.geoffray at lip6.fr  Thu Jun  4 11:48:42 2009
From: nicolas.geoffray at lip6.fr (Nicolas Geoffray)
Date: Thu, 04 Jun 2009 20:48:42 +0200
Subject: [LLVMdev] SSI and ABCD for LLVM
In-Reply-To: <4A27D078.807@dcc.ufmg.br>
References: <4A27D078.807@dcc.ufmg.br>
Message-ID: <4A28170A.3020204@lip6.fr>

Dear Andre,

That's great! Thanks for the blog. I am really looking forward into 
using ABCD in vmkit!

Cheers,
Nicolas

Andre Tavares wrote:
> Dear Community,
>
> I'm working on a project for Google Summer of Code, to implement the 
> ABCD and Bitwidth analysis in LLVM. I'm not going to extend the 
> description of the project here, this link shows my proposal 
> http://homepages.dcc.ufmg.br/~andrelct/projects/gsoc_2009/proposal.
>
> I have been in some discussions on this list about Ada and SSI that 
> helped on my decisions up to this moment.
>
> This project is due to August, and during this period I will be posting 
> my progress in a blog. If someone has interest in following my progress 
> I welcome you to read the blog, and I would really appreciate any 
> suggestion, critics and opinions on any aspect. I understand that every 
> opinion is helpful. So the blog link is 
> http://gsoc2009-andrelct.blogspot.com/.
>
> Best Regards,
>
>   



From lhames at gmail.com  Thu Jun  4 11:57:06 2009
From: lhames at gmail.com (Lang Hames)
Date: Thu, 4 Jun 2009 11:57:06 -0700
Subject: [LLVMdev] Removing SimpleRewriter (formerly SimpleSpiller)
In-Reply-To: <10F73596-5E3E-49B3-8920-3E72D17F0535@apple.com>
References: <728927c70906031334l307ba6a0l71a13b10bf7976c8@mail.gmail.com>
	<98BC26EF-5A97-4425-AA7A-4D2D0E11CCC5@apple.com>
	<10F73596-5E3E-49B3-8920-3E72D17F0535@apple.com>
Message-ID: <728927c70906041157q136d9777u8d12cf9c052e092d@mail.gmail.com>

R.I.P. SimpleRewriter. If anyone needs it resurrected let me know.

This leaves LocalRewriter (the default) and the new TrivialRewriter,
which is for use only with the new in-place spilling framework. This
framework appears (if you squint just right) to be basically
functional now, but it produces awful code. If you want to play with
it you can invoke it with the magical combination of
"-join-liveintervals=false -new-spill-framework -rewriter=trivial".

- Lang.

On Wed, Jun 3, 2009 at 10:46 PM, Chris Lattner <clattner at apple.com> wrote:
> On Jun 3, 2009, at 5:51 PM, Evan Cheng wrote:
>> I vote for execution of SimpleRewriter.
>
> Yeah, go ahead and axe it: Off with its head!
>
> -Chris
>
>>
>>
>> Evan
>>
>> On Jun 3, 2009, at 1:34 PM, Lang Hames wrote:
>>
>>> Hi all,
>>>
>>> Is anyone still using SimpleRewriter (formerly known as
>>> SimpleSpiller)? A quick check with the test suite suggests that it's
>>> badly broken. If it's not being used I'd like to remove it as part of
>>> my tidy-up of the register allocator.
>>>
>>> - Lang.
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>



From wjjeon at gmail.com  Thu Jun  4 11:59:43 2009
From: wjjeon at gmail.com (Won J Jeon)
Date: Thu, 4 Jun 2009 13:59:43 -0500
Subject: [LLVMdev] Current status of ARM backend (system-level support
	specifically) on LLVM?
Message-ID: <b8b15f5e0906041159h29c77202n38320bd3ead28f2b@mail.gmail.com>

Thanks, Eli. Also, I wonder specifically if the structure alignment and code
padding in the system code works with ARM backend without any problem, so
LLVM behaves the same as gcc.

Won

On Tue, Jun 2, 2009 at 11:58 AM, Won J Jeon<wjjeon at
gmail.com<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>>
wrote:
>* Hello all,
*>*
*>* We just started to look at how we could use LLVM to secure ARM-based
mobile
*>* system from malware like overriding pointers to system functions and
causing
*>* memory overflow. I'm wondering how the current ARM backend work on the
*>* current LLVM release.
*
It's stabe enough to be usable, as far as I know.

>* Does it have any support for ARM system-level
*>* instructions to change the page tables or switching tasks?
*
You can use inline assembly for this sort of thing.

-Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090604/b4c0c498/attachment.html>

From murat8307 at yahoo.com  Thu Jun  4 12:41:25 2009
From: murat8307 at yahoo.com (Murat B)
Date: Thu, 4 Jun 2009 12:41:25 -0700 (PDT)
Subject: [LLVMdev] Compilation error in 64 Bit PowerPC machine with
	Yellowdog Linux 6.1
Message-ID: <990442.96160.qm@web63202.mail.re1.yahoo.com>

Hi,

i am trying to compile llvm in a 64 Bit PowerPC machine with Yellowdog Linux 6.1 operating system. I could compile llvm but when I was trying to compile the llvm-gcc4.2 front end the compilation aborted with following error message:

../../gcc/config/rs6000/rs6000.c: In function ‘rs6000_override_options’:
../../gcc/config/rs6000/rs6000.c:1510: error: ‘MASK_MACHO_DYNAMIC_NO_PIC’ undeclared (first use in this function)
../../gcc/config/rs6000/rs6000.c:1510: error: (Each undeclared identifier is reported only once
../../gcc/config/rs6000/rs6000.c:1510: error: for each function it appears in.)
../../gcc/config/rs6000/rs6000.c: In function ‘rs6000_emit_prologue’:
../../gcc/config/rs6000/rs6000.c:16744: warning: implicit declaration of function ‘VECTOR_SAVE_INLINE’
../../gcc/config/rs6000/rs6000.c:16745: error: ‘lr_already_set_up_for_pic’ undeclared (first use in this function)
../../gcc/config/rs6000/rs6000.c: In function ‘rs6000_output_mi_thunk’:
../../gcc/config/rs6000/rs6000.c:18193: warning: implicit declaration of function ‘add_compiler_branch_island’
../../gcc/config/rs6000/rs6000.c:18193: warning: assignment makes pointer from integer without a cast
../../gcc/config/rs6000/rs6000.c:19886:8: warning: extra tokens at end of #endif directive
In file included from ../../gcc/config/rs6000/rs6000.c:22183:
./gt-rs6000.h: At top level:
./gt-rs6000.h:138: error: ‘branch_island_list’ undeclared here (not in a function)
make[2]: *** [rs6000.o] Error 1
make[2]: Leaving directory `/home/bolat/llvm-gcc4.2-2.2.source/obj/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/home/bolat/llvm-gcc4.2-2.2.source/obj'
make: *** [all] Error 2

Has anyone met similar problem and solved it? I appreciate your help.

Thanks,
Murat




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090604/c6653d3d/attachment.html>

From manoel at fonetica.com.br  Thu Jun  4 12:49:11 2009
From: manoel at fonetica.com.br (=?ISO-8859-1?Q?Manoel=20Teixeira?=)
Date: Thu,  4 Jun 2009 16:49:11 -0300
Subject: [LLVMdev] Structure Alignment
In-Reply-To: <mailman.1.1244134801.12478.llvmdev@cs.uiuc.edu>
References: <mailman.1.1244134801.12478.llvmdev@cs.uiuc.edu>
Message-ID: <20090604194911.8072.qmail@hm885.locaweb.com.br>

struct xfirstStru
{
    int                var1;
    double            var2;
    int                var3;
    char    *var4;
};
%FIRSTSTRU_PLUSPLUS_TOTVS. = type { i32, double, i32, i8* }

Hi,

I had not applied the layout at run time, only during the emission of the .bc.
Now it's running ok when I allocate the structure point at LLVM side, but, when I allocate the structure  pointer in the C side, the LLVM function does not acquire the double value correctly.
Manoel Teixeira

> Message: 1
> Date: Thu,  4 Jun 2009 10:39:24 -0300
> From: " Manoel Teixeira " <manoel at fonetica.com.br>
> Subject: [LLVMdev] Structure Alignment
> To: llvmdev at cs.uiuc.edu
> Message-ID: <20090604133924.4200.qmail at hm885.locaweb.com.br>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Hi,
> I have a problem using structs, when calling a function written in C from
> a LLVM function or calling a LLVM function from a C one.
> I noticed that the LLVM align double with 4 bytes and our run time routines
> use 8, in MS Windows.
> If a use #pragma pack(4) in my C programs, the routines run fine, but
> I must ensure that all external call should use the #pragma directive.
> 
> If I change the llvm layout f64:64:64, the LLVM calls C functions and
> the struct is OK, in the C side, but the getelemntptr fails in LLVM side.
> Is there on way to ensure that the LLVM reads the correct memory position
> in this case?
> 
> //#pragma pack(4)
> struct xfirstStru
> {
>     int                var1;
>     double            var2;
>     int                var3;
>     char    *var4;
> };
> typedef struct xfirstStru osX ;
> typedef struct xfirstStru* PosX ;
> //#pragma pack()
> //
> extern "C" int testOSX(    PosX osx    )
> {
>     printf("\nChamada C %d %f %d %s",++osx->var1,++osx->var2,++osx->var3,osx->var4);
>     return 999;
> }
> 
> it was
> ... f64:32:64 ...
> and I changed it to
> ... f64:64:64 ...
> 
> %struct.VAR1. = getelementptr %FIRSTSTRU.* %OUTRASTRU., i32 0, i32 0        ; <i32*> [#uses=2]    %loadX = load i32* %struct.el.VAR1., align 4        ; <i32> [#uses=1]
> here the first element is OK
> ...
> %struct.el.VAR2. = getelementptr %FIRSTSTRU.* %OUTRASTRU., i32 0, i32 1        ; <i32*> [#uses=2]    %loadX = load double* %struct.el.VAR2., align 8        ; <double> [#uses=1]
> here, the second is wrong
> ...
> 
> 
> Thanks,
> Manoel Teixeira
> 



From dag at cray.com  Thu Jun  4 13:06:03 2009
From: dag at cray.com (David Greene)
Date: Thu, 4 Jun 2009 15:06:03 -0500
Subject: [LLVMdev] TableGen Type Inference
Message-ID: <200906041506.03863.dag@cray.com>

Can someone explain why TableGen can't figure this out?

VCVTDQ2PS128rm: 	(set:isVoid VR128:v4f32:$dst, (sint_to_fp:v4f32 
(bitconvert:isInt (ld:v4i32 addr:iPTR:$src)<<P:Predicate_memop>>)))
llvm/tblgen: In VCVTDQ2PS128rm: Could not infer all types in pattern!

The pattern as written looks like this:

[(set VR128:$dst, (v4f32 (sint_to_fp (bc_memopv4i32 addr:$src))))]

I'm trying to unify AVX/SSE converts in a reasonable way.  Right now,
X86InstrSSE.td doesn't have patterns for sint_to_fp and fp_to_sint
with memory operands.  I guess this is why, but I don't understand
why it's illegal.

                                 -Dave


From eli.friedman at gmail.com  Thu Jun  4 13:32:06 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Thu, 4 Jun 2009 13:32:06 -0700
Subject: [LLVMdev] Current status of ARM backend (system-level support
	specifically) on LLVM?
In-Reply-To: <b8b15f5e0906041159h29c77202n38320bd3ead28f2b@mail.gmail.com>
References: <b8b15f5e0906041159h29c77202n38320bd3ead28f2b@mail.gmail.com>
Message-ID: <f5aa3e9b0906041332n53277c44pdf69f5ebfe44d986@mail.gmail.com>

On Thu, Jun 4, 2009 at 11:59 AM, Won J Jeon<wjjeon at gmail.com> wrote:
> Thanks, Eli. Also, I wonder specifically if the structure alignment and code
> padding in the system code works with ARM backend without any problem, so
> LLVM behaves the same as gcc.

llvm-gcc should generally produce equivalent code to gcc; if you find
any cases where it doesn't, please file a bug.  And if you're
generating IR yourself, LLVM should provide sufficient facilities to
generate correct code.

-Eli



From dalej at apple.com  Thu Jun  4 13:42:21 2009
From: dalej at apple.com (Dale Johannesen)
Date: Thu, 4 Jun 2009 13:42:21 -0700
Subject: [LLVMdev] Compilation error in 64 Bit PowerPC machine
	with	Yellowdog Linux 6.1
In-Reply-To: <990442.96160.qm@web63202.mail.re1.yahoo.com>
References: <990442.96160.qm@web63202.mail.re1.yahoo.com>
Message-ID: <45755482-6213-4BAA-B661-1E0036D033B0@apple.com>


On Jun 4, 2009, at 12:41 PMPDT, Murat B wrote:

> Hi,
>
> i am trying to compile llvm in a 64 Bit PowerPC machine with  
> Yellowdog Linux 6.1 operating system. I could compile llvm but when  
> I was trying to compile the llvm-gcc4.2 front end the compilation  
> aborted with following error message:

That looks like you have old sources, I fixed this crash a while  
back.  See PR 3099.

But note that PPC on Linux is not done, there are probably lots of ABI  
incompatibilities and I don't think anybody has gotten it to  
completely build and work.  Current state is in that PR.

> ../../gcc/config/rs6000/rs6000.c: In function  
> ‘rs6000_override_options’:
> ../../gcc/config/rs6000/rs6000.c:1510: error:  
> ‘MASK_MACHO_DYNAMIC_NO_PIC’ undeclared (first use in this function)
> ../../gcc/config/rs6000/rs6000.c:1510: error: (Each undeclared  
> identifier is reported only once
> ../../gcc/config/rs6000/rs6000.c:1510: error: for each function it  
> appears in.)
> ../../gcc/config/rs6000/rs6000.c: In function ‘rs6000_emit_prologue’:
> ../../gcc/config/rs6000/rs6000.c:16744: warning: implicit  
> declaration of function ‘VECTOR_SAVE_INLINE’
> ../../gcc/config/rs6000/rs6000.c:16745: error:  
> ‘lr_already_set_up_for_pic’ undeclared (first use in this function)
> ../../gcc/config/rs6000/rs6000.c: In function  
> ‘rs6000_output_mi_thunk’:
> ../../gcc/config/rs6000/rs6000.c:18193: warning: implicit  
> declaration of function ‘add_compiler_branch_island’
> ../../gcc/config/rs6000/rs6000.c:18193: warning: assignment makes  
> pointer from integer without a cast
> ../../gcc/config/rs6000/rs6000.c:19886:8: warning: extra tokens at  
> end of #endif directive
> In file included from ../../gcc/config/rs6000/rs6000.c:22183:
> ./gt-rs6000.h: At top level:
> ./gt-rs6000.h:138: error: ‘branch_island_list’ undeclared here (not  
> in a function)
> make[2]: *** [rs6000.o] Error 1
> make[2]: Leaving directory `/home/bolat/llvm-gcc4.2-2.2.source/obj/ 
> gcc'
> make[1]: *** [all-gcc] Error 2
> make[1]: Leaving directory `/home/bolat/llvm-gcc4.2-2.2.source/obj'
> make: *** [all] Error 2
>
> Has anyone met similar problem and solved it? I appreciate your help.
>
> Thanks,
> Murat
>
>
> _______________________________________________
> 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.llvm.org/pipermail/llvm-dev/attachments/20090604/6fa45048/attachment.html>

From dag at cray.com  Thu Jun  4 13:46:03 2009
From: dag at cray.com (David Greene)
Date: Thu, 4 Jun 2009 15:46:03 -0500
Subject: [LLVMdev] Removing SimpleRewriter (formerly SimpleSpiller)
In-Reply-To: <728927c70906041157q136d9777u8d12cf9c052e092d@mail.gmail.com>
References: <728927c70906031334l307ba6a0l71a13b10bf7976c8@mail.gmail.com>
	<10F73596-5E3E-49B3-8920-3E72D17F0535@apple.com>
	<728927c70906041157q136d9777u8d12cf9c052e092d@mail.gmail.com>
Message-ID: <200906041546.03491.dag@cray.com>

On Thursday 04 June 2009 13:57, Lang Hames wrote:
> R.I.P. SimpleRewriter. If anyone needs it resurrected let me know.
>
> This leaves LocalRewriter (the default) and the new TrivialRewriter,
> which is for use only with the new in-place spilling framework. This
> framework appears (if you squint just right) to be basically
> functional now, but it produces awful code. If you want to play with
> it you can invoke it with the magical combination of
> "-join-liveintervals=false -new-spill-framework -rewriter=trivial".

What's the "new spill framework?"

                               -Dave


From pertti.kellomaki at tut.fi  Thu Jun  4 13:55:04 2009
From: pertti.kellomaki at tut.fi (=?ISO-8859-1?Q?Pertti_Kellom=E4ki?=)
Date: Thu, 04 Jun 2009 22:55:04 +0200
Subject: [LLVMdev] LLVM frontend supporting arbitrary bit-width integral
 datatypes
In-Reply-To: <op.uuwe38tn0lgsd9@localhost.localdomain>
References: <op.uuwe38tn0lgsd9@localhost.localdomain>
Message-ID: <4A2834A8.2080402@tut.fi>

Hi Adam,

John is right, the TCE stuff would be useful for you. Our
compiler targets a processor template that the designer can
populate pretty freely. The compiler then reads the architecture
description and creates an LLVM backend on the fly.

Please don't hesitate to get in touch with us if you have
questions.
-- 
Pertti


From anton at korobeynikov.info  Thu Jun  4 14:00:14 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Fri, 05 Jun 2009 01:00:14 +0400
Subject: [LLVMdev] Compilation error in 64 Bit PowerPC machine with
 Yellowdog Linux 6.1
In-Reply-To: <990442.96160.qm@web63202.mail.re1.yahoo.com>
References: <990442.96160.qm@web63202.mail.re1.yahoo.com>
Message-ID: <1244149214.18321.384.camel@aslstation>

Hello,

> make[2]: Leaving directory
> `/home/bolat/llvm-gcc4.2-2.2.source/obj/gcc'
> make[1]: *** [all-gcc] Error 2
> make[1]: Leaving directory `/home/bolat/llvm-gcc4.2-2.2.source/obj'
> make: *** [all] Error 
Huh? 2.2 is awesome old. Consider using the sources from svn HEAD.

-- 
With best regards, Anton Korobeynikov.

Faculty of Mathematics & Mechanics, Saint Petersburg State University.



From anton at korobeynikov.info  Thu Jun  4 14:02:37 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Fri, 05 Jun 2009 01:02:37 +0400
Subject: [LLVMdev] Structure Alignment
In-Reply-To: <20090604194911.8072.qmail@hm885.locaweb.com.br>
References: <mailman.1.1244134801.12478.llvmdev@cs.uiuc.edu>
	<20090604194911.8072.qmail@hm885.locaweb.com.br>
Message-ID: <1244149357.18321.386.camel@aslstation>

Hello,

> I had not applied the layout at run time, only during the emission of the .bc.
> Now it's running ok when I allocate the structure point at LLVM side, but, when
> I allocate the structure  pointer in the C side,
> the LLVM function does not acquire the double value correctly.
LLVM has no idea about any weird requirements of struct fields padding /
alignment. You have to insert necessary padding fields by yourself (as
all frontends do).

-- 
With best regards, Anton Korobeynikov.

Faculty of Mathematics & Mechanics, Saint Petersburg State University.



From Micah.Villmow at amd.com  Thu Jun  4 16:59:53 2009
From: Micah.Villmow at amd.com (Villmow, Micah)
Date: Thu, 4 Jun 2009 16:59:53 -0700
Subject: [LLVMdev] Subsuming a memory node of a TargetGlobalAddress with a
	TargetConstant node
Message-ID: <493720826E33B1459E7F5C253E6D4BB5236989@ssanexmb2.amd.com>

I am trying to removing a load to a TargetGlobalAddress in ISelDagToDag
that my backend does not support. The TargetGlobalAddress is assumed to
always be of ConstantInt or ConstantFP type, so this transformation is
valid. I am correctly able to modify the dag and remove all of the uses
of the node as specified in the attached before and after dot images.
The nodes in question is the CUSTOM_ADD_i32(0x002EDE80) ->
load(0x002EDAC8), but I am not able to figure out how to correctly
modify the chain and point the TokenFactor(0x002EDBD8) node to the
llvm.opencl.other.get.global.id(0x002ED3E0) node so that I can
completely remove the load, undef, and targetglobaladdress nodes.

 

If anyone can give me any hints on how I can do this, it would be
greatly appreciated. I am already creating a target specific constant
and then using DAG->ReplaceAllUsesOfValueWith(Op, SDValue(N, 0)) to
remove the first connect, but I'm not sure how to remove the chain.

 

Thanks for your time,

Micah 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090604/a4ba9bfc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: before.dot
Type: application/octet-stream
Size: 9734 bytes
Desc: before.dot
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090604/a4ba9bfc/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: after.dot
Type: application/octet-stream
Size: 9734 bytes
Desc: after.dot
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090604/a4ba9bfc/attachment-0001.obj>

From lhames at gmail.com  Thu Jun  4 17:03:37 2009
From: lhames at gmail.com (Lang Hames)
Date: Thu, 4 Jun 2009 17:03:37 -0700
Subject: [LLVMdev] Removing SimpleRewriter (formerly SimpleSpiller)
In-Reply-To: <200906041546.03491.dag@cray.com>
References: <728927c70906031334l307ba6a0l71a13b10bf7976c8@mail.gmail.com>
	<10F73596-5E3E-49B3-8920-3E72D17F0535@apple.com>
	<728927c70906041157q136d9777u8d12cf9c052e092d@mail.gmail.com>
	<200906041546.03491.dag@cray.com>
Message-ID: <728927c70906041703j6b71a16sfb854b1dd258765c@mail.gmail.com>

The new spilling framework inserts spill code in-place (during
register allocation) rather than deferring it using
VirtRegMap/VirtRegRewriter. The goal is to enable techniques like
iterative splitting to be implemented. It should also be a bit tidier
as it keeps more state in the MachineFunction, rather than in
book-keeping structures like VirtRegMap. The work is in the very early
stages though.

- Lang.

On Thu, Jun 4, 2009 at 1:46 PM, David Greene <dag at cray.com> wrote:
> On Thursday 04 June 2009 13:57, Lang Hames wrote:
>> R.I.P. SimpleRewriter. If anyone needs it resurrected let me know.
>>
>> This leaves LocalRewriter (the default) and the new TrivialRewriter,
>> which is for use only with the new in-place spilling framework. This
>> framework appears (if you squint just right) to be basically
>> functional now, but it produces awful code. If you want to play with
>> it you can invoke it with the magical combination of
>> "-join-liveintervals=false -new-spill-framework -rewriter=trivial".
>
> What's the "new spill framework?"
>
>                               -Dave
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>



From haohui.mai at gmail.com  Thu Jun  4 17:22:23 2009
From: haohui.mai at gmail.com (Mai, Haohui)
Date: Thu, 04 Jun 2009 19:22:23 -0500
Subject: [LLVMdev] SSI and ABCD for LLVM
In-Reply-To: <4A28170A.3020204@lip6.fr>
References: <4A27D078.807@dcc.ufmg.br>  <4A28170A.3020204@lip6.fr>
Message-ID: <1244161343.3936.1.camel@haohui-laptop>

Dear Nicolas,

I'm curious why you are using ABCD in vmkit. Do you need any features
from static array bounds checking? As far as I know, SAFECode has a
number of implementation for that.

Thanks.

Haohui 

On Thu, 2009-06-04 at 20:48 +0200, Nicolas Geoffray wrote:
> Dear Andre,
> 
> That's great! Thanks for the blog. I am really looking forward into 
> using ABCD in vmkit!
> 
> Cheers,
> Nicolas
> 
> Andre Tavares wrote:
> > Dear Community,
> >
> > I'm working on a project for Google Summer of Code, to implement the 
> > ABCD and Bitwidth analysis in LLVM. I'm not going to extend the 
> > description of the project here, this link shows my proposal 
> > http://homepages.dcc.ufmg.br/~andrelct/projects/gsoc_2009/proposal.
> >
> > I have been in some discussions on this list about Ada and SSI that 
> > helped on my decisions up to this moment.
> >
> > This project is due to August, and during this period I will be posting 
> > my progress in a blog. If someone has interest in following my progress 
> > I welcome you to read the blog, and I would really appreciate any 
> > suggestion, critics and opinions on any aspect. I understand that every 
> > opinion is helpful. So the blog link is 
> > http://gsoc2009-andrelct.blogspot.com/.
> >
> > Best Regards,
> >
> >   
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



From dodohack at gmail.com  Thu Jun  4 17:41:49 2009
From: dodohack at gmail.com (dodo)
Date: Fri, 5 Jun 2009 08:41:49 +0800
Subject: [LLVMdev] endian issue of llvm-gcc and llvm backend
Message-ID: <e6010ba80906041741m14aa05efl11859b79e79ef272@mail.gmail.com>

Hello, Sam

I used non-arm backend, and I used a target which likes mips has both big
and little endianness. And I have ported llvm-gcc to this platform along
with llvm backend.
The issue is about IR endianness and how backend deal with the data and
instructions in different endian, since I discovered 2 different IR
generates the same asm code by llc for different endian target.


> Message: 27
> Date: Thu, 4 Jun 2009 05:22:07 -0700 (PDT)
> From: Samuel Crow <samuraileumas at yahoo.com>
> Subject: Re: [LLVMdev] endian issue of llvm-gcc and llvm backend
> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Message-ID: <157221.53893.qm at web62002.mail.re1.yahoo.com>
> Content-Type: text/plain; charset=us-ascii
>
>
> Hello,
>
> According to the frequently asked questions on the LLVM webpage, C++ and C
> cannot currently be used for platform indedpendent usage.  Your discovery
> doesn't fall on one of the often discovered problems though so it may be a
> bug in the ARM backend.  The ARM backend is considered to be experimental at
> this point so it is likely to have incorrect code in it.
>
> I hope I answered your question well enough,
>
> --Sam
> ________________________________
> From: dodo <dodohack at gmail.com>
> To: llvmdev at cs.uiuc.edu
> Sent: Thursday, June 4, 2009 3:14:28 AM
> Subject: [LLVMdev] endian issue of llvm-gcc and llvm backend
>
> Hi, all
>
> As I'm a Chinese, be patient of my poor description below.
>
> I compiled libgcc into llvm bitcode in both big endian and little endian.
> and got 2 different version of function: _ashldi3, the following is the
> fragment of this function:
>
> little endian:
> =============================================
> ......
> target datalayout =
> "e-p:32:32:32-i1:8:8-i8:8:32-i16:16:32-i32:32:32-i64:32:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64"
> target triple = "nds32le-linux"
>
> define i64 @__ashldi3(i64 %u, i32 %b) nounwind readnone {
> entry:
>        %0 = icmp eq i32 %b, 0          ; <i1> [#uses=1]
>        br i1 %0, label %bb5, label %bb1
>
> bb1:            ; preds = %entry
>        %1 = trunc i64 %u to i32                ; <i32> [#uses=3]
>        %2 = sub i32 32, %b             ; <i32> [#uses=3]
>        %3 = icmp sgt i32 %2, 0         ; <i1> [#uses=1]
>        br i1 %3, label %bb3, label %bb2
> ......
> ==============================================
>
> big endian:
> ==============================================
> ......
> target datalayout =
> "E-p:32:32:32-i1:8:8-i8:8:32-i16:16:32-i32:32:32-i64:32:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64"
> target triple = "nds32-linux"
>
> define i64 @__ashldi3(i64 %u, i32 %b) nounwind readnone {
> entry:
>        %0 = icmp eq i32 %b, 0          ; <i1> [#uses=1]
>        br i1 %0, label %bb5, label %bb1
>
> bb1:            ; preds = %entry
>        %sroa.store.elt = lshr i64 %u, 32               ; <i64> [#uses=1]
>        %1 = trunc i64 %sroa.store.elt to i32           ; <i32> [#uses=3]
>        %2 = sub i32 32, %b             ; <i32> [#uses=3]
>        %3 = icmp sgt i32 %2, 0         ; <i1> [#uses=1]
>        br i1 %3, label %bb3, label %bb2
> ......
> ==============================================
>
> >From the generated IR, we could see that llvm IR is endian dependent and
> it know how to get the low 32 bits of a 64 bits parameter.
>
> While generate asm code from these 2 different IR,  I got the same asm
> code.
> The following is the asm code which are mips like:
> (NOTE: $rx indicates a 32 bits register x, #x indicates constant, subri
> $r3, $r2, #32 means r3 = 32 - r2,
> r0, r1 contain the first 64 bits parameter which contains %u, r2 contains
> the second parameter %b)
>
> beqz $r2,83f6 <__ashldi3+0x2a>
> subri $r3,$r2,#32
> blez $r3,83fa <__ashldi3+0x2e>
> sll $r1,$r1,$r2
> srl $r3,$r0,$r3
> or $r3,$r3,$r1
> sll $r1,$r0,$r2
> movi $r2,#0
> mov $r0,$r1
> or $r1,$r3,$r2
> ret $lp
> ret $lp
> subri $r3,$r3,#0
> movi $r1,#0
> sll $r3,$r0,$r3
>
> The above asm code is tested ok in little endian, and not ok in big endian,
> because it does not get paramter %u correctly, for big endian, r0, r1 in
>  that asm code should be exchanged  for endian  issue.
>
> One possible reason is that I generate code for big endian and llvm-gcc
> really generates big endian IR for me(from the presented IR, it did). Then I
> use llc to generate asm code, llc eat the target triple and/or datalayout
> from the bitcode and generates big endian asm code for me again.
> The result is that:  llvm-gcc gen'ed big endian code + llc gen'ed big
> endian code = little endian code, am I right?
>
> If I want to generate correct asm code for big endian? what should I do?
> I have tried to generate big endian asm code from little endian IR by
> giving -march option to llc to force the target to big endian, but this
> seems to be unworkable!
>
>
-- 
dodohack at ybu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090605/38911e2e/attachment.html>

From andrelct at dcc.ufmg.br  Thu Jun  4 18:33:23 2009
From: andrelct at dcc.ufmg.br (Andre Tavares)
Date: Thu, 04 Jun 2009 22:33:23 -0300
Subject: [LLVMdev] SSI and ABCD for LLVM
In-Reply-To: <1244161343.3936.1.camel@haohui-laptop>
References: <4A27D078.807@dcc.ufmg.br> <4A28170A.3020204@lip6.fr>
	<1244161343.3936.1.camel@haohui-laptop>
Message-ID: <4A2875E3.9070706@dcc.ufmg.br>

Mai, Haohui wrote:
> Dear Nicolas,
>
> I'm curious why you are using ABCD in vmkit. Do you need any features
> from static array bounds checking? As far as I know, SAFECode has a
> number of implementation for that.
>
> Thanks.
>
> Haohui 
>
> On Thu, 2009-06-04 at 20:48 +0200, Nicolas Geoffray wrote:
>   
>> Dear Andre,
>>
>> That's great! Thanks for the blog. I am really looking forward into 
>> using ABCD in vmkit!
>>
>> Cheers,
>> Nicolas
>>
>> Andre Tavares wrote:
>>     
>>> Dear Community,
>>>
>>> I'm working on a project for Google Summer of Code, to implement the 
>>> ABCD and Bitwidth analysis in LLVM. I'm not going to extend the 
>>> description of the project here, this link shows my proposal 
>>> http://homepages.dcc.ufmg.br/~andrelct/projects/gsoc_2009/proposal.
>>>
>>> I have been in some discussions on this list about Ada and SSI that 
>>> helped on my decisions up to this moment.
>>>
>>> This project is due to August, and during this period I will be posting 
>>> my progress in a blog. If someone has interest in following my progress 
>>> I welcome you to read the blog, and I would really appreciate any 
>>> suggestion, critics and opinions on any aspect. I understand that every 
>>> opinion is helpful. So the blog link is 
>>> http://gsoc2009-andrelct.blogspot.com/.
>>>
>>> Best Regards,
>>>
>>>   
>>>       
>> _______________________________________________
>> 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
>
>   
Sorry if my description was too short, but I will be removing 
unnecessary array bound checks, not creating them.

-- 
Andre Tavares
Master Student in Computer Science - UFMG - Brasil
http://dcc.ufmg.br/~andrelct



From sanjiv.gupta at microchip.com  Thu Jun  4 23:51:14 2009
From: sanjiv.gupta at microchip.com (Sanjiv Gupta)
Date: Fri, 05 Jun 2009 12:21:14 +0530
Subject: [LLVMdev] llvmc for PIC16
In-Reply-To: <loom.20090604T142600-116@post.gmane.org>
References: <4A2633E9.4070207@microchip.com>
	<loom.20090604T142600-116@post.gmane.org>
Message-ID: <4A28C062.9060307@microchip.com>


> I'll be happy to answer any further questions you may have, feel free to e-mail
> me directly (though right now our mail server is down)
>   
The salient features that we want to have in the driver are:
1. llvm-ld will be used as "The Optimizer".
2. If the user has specified to generate the final executable, then 
llvm-ld should run on all the .bc files generated by clang and create a 
single optimized .bc file for further tools.
3. -Wo <options> - pass optimizations to the llvm-ld
4. mcc16 -Wl <options> - pass options to native linker.
5. mcc16 -Wa <options> - pass options to native assembler.

Here are some example command lines and sample command invocations as to 
what should be done.

$ mcc16 -S foo.c
// [clang-cc foo.c] -> foo.bc
// [llvm-ld foo.bc] -> foo.opt.bc
// [llc foo.opt.bc] -> foo.s

$ mcc16 -S foo.c bar.c
// [clang-cc foo.c] -> foo.bc
// [llvm-ld foo.bc] -> foo.opt.bc
// [llc foo.opt.bc] -> foo.s
// [clang-cc bar.c] -> bar.bc
// [llvm-ld bar.bc] -> bar.opt.bc
// [llc bar.opt.bc] -> bar.s

** Use of -g causes llvm-ld to run with -disable-opt
$ mcc16 -S -g foo.c
// [clang-cc foo.c] -> foo.bc
// [llvm-ld -disable-opt foo.bc] -> foo.opt.bc
// [llc foo.opt.bc] -> foo.s

** -I is passed to clang-cc, -pre-RA-sched=list-burr to llc.
$ mcc16 -S -g -I ../include -pre-RA-sched=list-burr foo.c
// [clang-cc -I ../include foo.c] -> foo.bc
// [llvm-ld -disable-opt foo.bc] -> foo.opt.bc
// [llc -pre-RA-sched=list-burr foo.opt.bc] -> foo.s

** -Wo passes options to llvm-ld
$ mcc16 -Wo=opt1,opt2 -S -I ../include -pre-RA-sched=list-burr foo.c
// [clang-cc -I ../include foo.c] -> foo.bc
// [llvm-ld -opt1 -opt2 foo.bc] -> foo.opt.bc
// [llc -pre-RA-sched=list-burr foo.opt.bc] -> foo.s

** -Wa passes options to native as.
$ mcc16 -c foo.c -Wa=opt1
// [clang-cc foo.c] -> foo.bc
// [llvm-ld foo.bc] -> foo.opt.bc
// [llc foo.opt.bc] -> foo.s
// [native-as -opt1 foo.s] -> foo.o

$ mcc16 -Wo=opt1 -Wl=opt2 -Wa=opt3 foo.c bar.c
// [clang-cc foo.c] -> foo.bc
// [clang-cc bar.c] -> bar.bc
// [llvm-ld -opt1 foo.bc bar.bc] -> a.out.bc
// [llc a.out.bc] -> a.out.s
// [native-as -opt3 a.out.s] -> a.out.o
// [native-ld -opt2 a.out.o] -> a.out

Is this achievable by a tablegen based driver ?

- Sanjiv




From camille at osculator.net  Fri Jun  5 02:49:40 2009
From: camille at osculator.net (Camille Troillard)
Date: Fri, 5 Jun 2009 11:49:40 +0200
Subject: [LLVMdev] Creating a LLVM Project from the Sample project
Message-ID: <de35c4ed0906050249x3bf76601m44ef5fdbe1381d0e@mail.gmail.com>

Hello,

I have followed the steps described in http://llvm.org/docs/Projects.html.
It seems there is a problem with the AutoRegen.sh script.
In order to get the whole sample project working in a directory
outside of llvm directory structure, I had to replace lines 22 and 23
by :

  llvm_src_root=../llvm
  llvm_obj_root=../llvm

I am not a configuration specialist, so I can't tell if this is a good
fix, but it works.
I should also add that in order to fully customize the sample project,
there is some additional work to rename existing directories and their
references in configure.ac.  These additional steps are not described
in the "Creating an LLVM Project" document.


Best,
Cam


From camille at osculator.net  Fri Jun  5 02:59:08 2009
From: camille at osculator.net (Camille Troillard)
Date: Fri, 5 Jun 2009 11:59:08 +0200
Subject: [LLVMdev] Using LLVM JIT inside a Cocoa application
Message-ID: <de35c4ed0906050259j7ddb378bo14256e1cd5516fb9@mail.gmail.com>

Hello,

I am trying to compile a project I am writing with Xcode that will use
LLVM libraries to generate code executed with the JIT.
I would be curious to learn how you deal with LLVM header files,
libraries, makefiles and Cocoa application projects.

My candid understanding is that LLVM projects need to be built with
LLVM makefiles (hence the previous message I sent about LLVM
Projects).  I am not totally reluctant to the idea of building a
library outside of Xcode and then linking it to my Cocoa project, but
I find it rather annoying to maintain two project structures.  With
some work it would be possible to automate all of this build project
inside Xcode, but I was hoping a more straightforward solution.

Any ideas?

Best Regards,
Camille


From devlists at shadowlab.org  Fri Jun  5 04:31:57 2009
From: devlists at shadowlab.org (Jean-Daniel Dupas)
Date: Fri, 5 Jun 2009 13:31:57 +0200
Subject: [LLVMdev] Using LLVM JIT inside a Cocoa application
In-Reply-To: <de35c4ed0906050259j7ddb378bo14256e1cd5516fb9@mail.gmail.com>
References: <de35c4ed0906050259j7ddb378bo14256e1cd5516fb9@mail.gmail.com>
Message-ID: <CDA48308-4CDC-4D04-8166-41BF51B7F658@shadowlab.org>

Hello,

I'm not an LLVM expert, but I think you can build a Cocoa/LLVM project  
by using the LLVM's libraries and headers the same way you did with  
any other third party library.

In fact, that's what the clang Xcode project does. It does not use any  
makefile.

In short:
	- Add the llvm/include folder in you header search path (in the  
project's build settings).

To add libraries, an option may be to drop the *.a you need in your  
Xcode project, and Xcode is smart enough to adjust the library search  
path as needed.

and other option (the one chosen by clang) may be to change build  
settings:
	- Add the llvm/<output>/lib/ folder in you library search path  
(replace <output> by the name of the llvm build dir. You can choose a  
value based on your build configuration to use different libraries  
variant in Debug and Release).
	- Add linker flags to tell the linker which LLVM libraries you want  
to use.



Le 5 juin 09 à 11:59, Camille Troillard a écrit :

> Hello,
>
> I am trying to compile a project I am writing with Xcode that will use
> LLVM libraries to generate code executed with the JIT.
> I would be curious to learn how you deal with LLVM header files,
> libraries, makefiles and Cocoa application projects.
>
> My candid understanding is that LLVM projects need to be built with
> LLVM makefiles (hence the previous message I sent about LLVM
> Projects).  I am not totally reluctant to the idea of building a
> library outside of Xcode and then linking it to my Cocoa project, but
> I find it rather annoying to maintain two project structures.  With
> some work it would be possible to automate all of this build project
> inside Xcode, but I was hoping a more straightforward solution.
>
> Any ideas?
>
> Best Regards,
> Camille
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>



From camille at osculator.net  Fri Jun  5 04:49:06 2009
From: camille at osculator.net (Camille Troillard)
Date: Fri, 5 Jun 2009 13:49:06 +0200
Subject: [LLVMdev] Using LLVM JIT inside a Cocoa application
In-Reply-To: <CDA48308-4CDC-4D04-8166-41BF51B7F658@shadowlab.org>
References: <de35c4ed0906050259j7ddb378bo14256e1cd5516fb9@mail.gmail.com>
	<CDA48308-4CDC-4D04-8166-41BF51B7F658@shadowlab.org>
Message-ID: <de35c4ed0906050449r24e266c6v1aea6ad7ff1f348@mail.gmail.com>

Bonjour Jean-Daniel,

I didn't know about the clang Xcode project, and indeed it works very naturally.
It seems the key to successfully build a project within Xcode is to set :

GCC_PREPROCESSOR_DEFINITIONS = __STDC_CONSTANT_MACROS __STDC_LIMIT_MACROS=1

I was fearing the makefiles were involving more work behind the
scenes, but that's not true: include the headers, libraries, and set
the C++ macros.

Thanks for the info!


Best,
Cam


On Fri, Jun 5, 2009 at 1:31 PM, Jean-Daniel Dupas<devlists at shadowlab.org> wrote:
> Hello,
>
> I'm not an LLVM expert, but I think you can build a Cocoa/LLVM project
> by using the LLVM's libraries and headers the same way you did with
> any other third party library.
>
> In fact, that's what the clang Xcode project does. It does not use any
> makefile.
>
> In short:
>        - Add the llvm/include folder in you header search path (in the
> project's build settings).
>
> To add libraries, an option may be to drop the *.a you need in your
> Xcode project, and Xcode is smart enough to adjust the library search
> path as needed.
>
> and other option (the one chosen by clang) may be to change build
> settings:
>        - Add the llvm/<output>/lib/ folder in you library search path
> (replace <output> by the name of the llvm build dir. You can choose a
> value based on your build configuration to use different libraries
> variant in Debug and Release).
>        - Add linker flags to tell the linker which LLVM libraries you want
> to use.
>
>
>
> Le 5 juin 09 à 11:59, Camille Troillard a écrit :
>
>> Hello,
>>
>> I am trying to compile a project I am writing with Xcode that will use
>> LLVM libraries to generate code executed with the JIT.
>> I would be curious to learn how you deal with LLVM header files,
>> libraries, makefiles and Cocoa application projects.
>>
>> My candid understanding is that LLVM projects need to be built with
>> LLVM makefiles (hence the previous message I sent about LLVM
>> Projects).  I am not totally reluctant to the idea of building a
>> library outside of Xcode and then linking it to my Cocoa project, but
>> I find it rather annoying to maintain two project structures.  With
>> some work it would be possible to automate all of this build project
>> inside Xcode, but I was hoping a more straightforward solution.
>>
>> Any ideas?
>>
>> Best Regards,
>> Camille
>> _______________________________________________
>> 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 haohui.mai at gmail.com  Fri Jun  5 07:26:02 2009
From: haohui.mai at gmail.com (Mai, Haohui)
Date: Fri, 5 Jun 2009 09:26:02 -0500
Subject: [LLVMdev] SSI and ABCD for LLVM
In-Reply-To: <4A2875E3.9070706@dcc.ufmg.br>
References: <4A27D078.807@dcc.ufmg.br> <4A28170A.3020204@lip6.fr>
	<1244161343.3936.1.camel@haohui-laptop>
	<4A2875E3.9070706@dcc.ufmg.br>
Message-ID: <4a292afe.04015a0a.5436.2327@mx.google.com>

By static array bounds checking, I mean eliminating array bounds checking
which can be proved ``safe'' at compile-time.

Well, even though there are a lot of approaches of doing this, I believe
that having an implementation of ABCD would very useful. It would be even
more useful if LLVM can have a general framework for doing static array
bounds checking -- just like the aliasing framework.

Haohui

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Andre Tavares
Sent: Thursday, June 04, 2009 8:33 PM
To: LLVM Developers Mailing List
Subject: Re: [LLVMdev] SSI and ABCD for LLVM

Mai, Haohui wrote:
> Dear Nicolas,
>
> I'm curious why you are using ABCD in vmkit. Do you need any features
> from static array bounds checking? As far as I know, SAFECode has a
> number of implementation for that.
>
> Thanks.
>
> Haohui 
>
> On Thu, 2009-06-04 at 20:48 +0200, Nicolas Geoffray wrote:
>   
>> Dear Andre,
>>
>> That's great! Thanks for the blog. I am really looking forward into 
>> using ABCD in vmkit!
>>
>> Cheers,
>> Nicolas
>>
>> Andre Tavares wrote:
>>     
>>> Dear Community,
>>>
>>> I'm working on a project for Google Summer of Code, to implement the 
>>> ABCD and Bitwidth analysis in LLVM. I'm not going to extend the 
>>> description of the project here, this link shows my proposal 
>>> http://homepages.dcc.ufmg.br/~andrelct/projects/gsoc_2009/proposal.
>>>
>>> I have been in some discussions on this list about Ada and SSI that 
>>> helped on my decisions up to this moment.
>>>
>>> This project is due to August, and during this period I will be posting 
>>> my progress in a blog. If someone has interest in following my progress 
>>> I welcome you to read the blog, and I would really appreciate any 
>>> suggestion, critics and opinions on any aspect. I understand that every 
>>> opinion is helpful. So the blog link is 
>>> http://gsoc2009-andrelct.blogspot.com/.
>>>
>>> Best Regards,
>>>
>>>   
>>>       
>> _______________________________________________
>> 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
>
>   
Sorry if my description was too short, but I will be removing 
unnecessary array bound checks, not creating them.

-- 
Andre Tavares
Master Student in Computer Science - UFMG - Brasil
http://dcc.ufmg.br/~andrelct

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



From sanjiv.gupta at microchip.com  Fri Jun  5 08:20:15 2009
From: sanjiv.gupta at microchip.com (Sanjiv Gupta)
Date: Fri, 05 Jun 2009 20:50:15 +0530
Subject: [LLVMdev] Subsuming a memory node of a TargetGlobalAddress with
 a	TargetConstant node
In-Reply-To: <493720826E33B1459E7F5C253E6D4BB5236989@ssanexmb2.amd.com>
References: <493720826E33B1459E7F5C253E6D4BB5236989@ssanexmb2.amd.com>
Message-ID: <4A2937AF.4010508@microchip.com>

Villmow, Micah wrote:
>
> I am trying to removing a load to a TargetGlobalAddress in 
> ISelDagToDag that my backend does not support. The TargetGlobalAddress 
> is assumed to always be of ConstantInt or ConstantFP type, so this 
> transformation is valid. I am correctly able to modify the dag and 
> remove all of the uses of the node as specified in the attached before 
> and after dot images. The nodes in question is the 
> CUSTOM_ADD_i32(0x002EDE80) -> load(0x002EDAC8), but I am not able to 
> figure out how to correctly modify the chain and point the 
> TokenFactor(0x002EDBD8) node to the 
> llvm.opencl.other.get.global.id(0x002ED3E0) node so that I can 
> completely remove the load, undef, and targetglobaladdress nodes.
>
> If anyone can give me any hints on how I can do this, it would be 
> greatly appreciated. I am already creating a target specific constant 
> and then using DAG->ReplaceAllUsesOfValueWith(Op, SDValue(N, 0)) to 
> remove the first connect, but I’m not sure how to remove the chain.
>
> Thanks for your time,
>
> Micah
>
>   
A load takes a chain as input and produces a chain as output. While 
removing the load node you can retrieve the incoming chain to load and 
put it where the out chain of load goes to.

In PIC16 backend, we replace "load" with pic16 specific load node called 
"PIC16Load". See if PIC16 code can help.

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



From dag at cray.com  Fri Jun  5 08:51:15 2009
From: dag at cray.com (David Greene)
Date: Fri, 5 Jun 2009 10:51:15 -0500
Subject: [LLVMdev] SSE Scalar Convert Intrinsics
Message-ID: <200906051051.16447.dag@cray.com>

I have a question about the SSE scalar convert intrinsics.

cvtsd2si is defined thusly:

  def int_x86_sse2_cvtsd2si64 : GCCBuiltin<"__builtin_ia32_cvtsd2si64">,
              Intrinsic<[llvm_i64_ty, llvm_v2f64_ty], [IntrNoMem]>;

This matches the signature of the GCC intrinsic.  The fact that the GCC
intrinsic has a type mismatch on the input (vector rather than scalar)
is strange, but ok, we'll run with it.

Until this:

def Int_CVTSD2SIrm : SDI<0x2D, MRMSrcMem, (outs GR32:$dst), (ins f128mem:
$src),
                         "cvtsd2si\t{$src, $dst|$dst, $src}",
                         [(set GR32:$dst, (int_x86_sse2_cvtsd2si
                                           (load addr:$src)))]>;

Er, this makes us load a 128-bit quantity, which is almost certainly not
what we want.

Do we need two intrinsics for these scalar converts, one to satisfy the
(arguably broken) GCC interface and one to really reflect the operation
as specified by the ISA?

                                   -Dave


From dag at cray.com  Fri Jun  5 08:55:55 2009
From: dag at cray.com (David Greene)
Date: Fri, 5 Jun 2009 10:55:55 -0500
Subject: [LLVMdev] Removing SimpleRewriter (formerly SimpleSpiller)
In-Reply-To: <728927c70906041703j6b71a16sfb854b1dd258765c@mail.gmail.com>
References: <728927c70906031334l307ba6a0l71a13b10bf7976c8@mail.gmail.com>
	<200906041546.03491.dag@cray.com>
	<728927c70906041703j6b71a16sfb854b1dd258765c@mail.gmail.com>
Message-ID: <200906051055.56245.dag@cray.com>

On Thursday 04 June 2009 19:03, Lang Hames wrote:
> The new spilling framework inserts spill code in-place (during
> register allocation) rather than deferring it using
> VirtRegMap/VirtRegRewriter. The goal is to enable techniques like
> iterative splitting to be implemented. It should also be a bit tidier
> as it keeps more state in the MachineFunction, rather than in
> book-keeping structures like VirtRegMap. The work is in the very early
> stages though.

Sounds good.

One thing I would recommend is that the code that does IR
changes be separated from the code (if any) that does dataflow
information updates.  The entanglement of these two functions
is part of the reason that the coalescing code is so complicated.
Separating the actions allows the code to be reused by other
passes (different register allocators, for example).

                               -Dave


From marcus.zetterquist at gmail.com  Fri Jun  5 05:30:37 2009
From: marcus.zetterquist at gmail.com (Marcus Zetterquist)
Date: Fri, 5 Jun 2009 14:30:37 +0200
Subject: [LLVMdev] How to stop
Message-ID: <CA2A3D1D-73DA-4F1F-9495-F55B23889FFB@gmail.com>

Hi!


Today we use Lua to let 3rd party developers add driver-like modules  
to our application.

The advantages to using Lua compared to DLL:s etc. are that:

1) the same driver binary can be used on all OS:es and processor  
architectures etc.

2) We can provide a small API to the Lua drivers and they _cannot_  
call any other external functions.

3) A buggy driver cannot crash our application. (Almost true statement.)


I'm looking into using LLVM and the bitcode format for this instead.  
The additional, very important advantages are:

4) 3rd parties can port existing (huge amounts of) C / C++ code much  
easier - no need to rewrite all code in Lua.

5) Performance. We will use the LLVM JIT.


Problem: I can't figure out how to do (2) with the LLVM JIT.

It is very important that the driver does not have access to any other  
function in the application except those I provide. It's not OK for  
our application to abort if a driver calls an undefined function - I  
want to just disable _that driver_ in that event.

I can use DisableSymbolSearching() but that causes application to  
abort for unknown symbols.


Please advice!


/Marcus



From marcus.zetterquist at gmail.com  Fri Jun  5 05:33:38 2009
From: marcus.zetterquist at gmail.com (Marcus Zetterquist)
Date: Fri, 5 Jun 2009 14:33:38 +0200
Subject: [LLVMdev] How to stop symbol searching without aborting
Message-ID: <421B2CED-8DC3-419E-8ACF-CB6643164214@gmail.com>

Hi!


Today we use Lua to let 3rd party developers add driver-like modules  
to our application.

The advantages to using Lua compared to DLL:s etc. are that:

1) the same driver binary can be used on all OS:es and processor  
architectures etc.

2) We can provide a small API to the Lua drivers and they _cannot_  
call any other external functions.

3) A buggy driver cannot crash our application. (Almost true statement.)


I'm looking into using LLVM and the bitcode format for this instead.  
The additional, very important advantages are:

4) 3rd parties can port existing (huge amounts of) C / C++ code much  
easier - no need to rewrite all code in Lua.

5) Performance. We will use the LLVM JIT.


Problem: I can't figure out how to do (2) with the LLVM JIT.

It is very important that the driver does not have access to any other  
function in the application except those I provide. It's not OK for  
our application to abort if a driver calls an undefined function - I  
want to just disable _that driver_ in that event.

I can use DisableSymbolSearching() but that causes application to  
abort for unknown symbols.


Please advice!


/Marcus


From varonrotem at gmail.com  Fri Jun  5 09:50:59 2009
From: varonrotem at gmail.com (Rotem Varon)
Date: Fri, 5 Jun 2009 12:50:59 -0400
Subject: [LLVMdev] Analysis Pass
Message-ID: <4f5edbea0906050950s495e9019pa4e93d54f7ef6df9@mail.gmail.com>

Hi,

I am trying to set a prerequisite pass.


void PassName::getAnalysisUsage(AnalysisUsage &AU) const
    {
        AU.setPreservesAll();
        AU.addRequired<LiveVariables>();
    }

But when i am running the pass with the opt i get this error:
undefined symbol: _ZN4llvm13LiveVariables2IDE

If you need more information ...

Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090605/c87b4ca1/attachment.html>

From ofv at wanadoo.es  Fri Jun  5 10:09:14 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Fri, 05 Jun 2009 19:09:14 +0200
Subject: [LLVMdev] How to stop symbol searching without aborting
References: <421B2CED-8DC3-419E-8ACF-CB6643164214@gmail.com>
Message-ID: <871vpyip51.fsf@telefonica.net>

Marcus Zetterquist <marcus.zetterquist at gmail.com> writes:

> Today we use Lua to let 3rd party developers add driver-like modules  
> to our application.
>
> The advantages to using Lua compared to DLL:s etc. are that:
>
> 1) the same driver binary can be used on all OS:es and processor  
> architectures etc.

[snip]

> I'm looking into using LLVM and the bitcode format for this instead.  
> The additional, very important advantages are:
>
> 4) 3rd parties can port existing (huge amounts of) C / C++ code much  
> easier - no need to rewrite all code in Lua.

AFAIK, LLVM code is not platform-independent. A C compiler that targets
x86 will generate different LLVM bitcode than the same C compiler when
it targets x86_64, for instance.

> 5) Performance. We will use the LLVM JIT.
>
>
> Problem: I can't figure out how to do (2) with the LLVM JIT.
>
> It is very important that the driver does not have access to any other  
> function in the application except those I provide. It's not OK for  
> our application to abort if a driver calls an undefined function - I  
> want to just disable _that driver_ in that event.
>
> I can use DisableSymbolSearching() but that causes application to  
> abort for unknown symbols.

An LLVM program can call any address, valid or not. If the programmer
figures out the address of one of those "forbidden" functions, he can
call it. You may write some pass for detecting suspicious constructs and
reject them, but solving the problem the right way looks very hard or
impossible to me, mostly because you want to use LLVM code generated by
a C/C++ compiler.

-- 
Óscar



From cedric.venet at laposte.net  Fri Jun  5 13:05:38 2009
From: cedric.venet at laposte.net (=?windows-1252?Q?C=E9dric_Venet?=)
Date: Fri, 05 Jun 2009 22:05:38 +0200
Subject: [LLVMdev] How to stop symbol searching without aborting
In-Reply-To: <871vpyip51.fsf@telefonica.net>
References: <421B2CED-8DC3-419E-8ACF-CB6643164214@gmail.com>
	<871vpyip51.fsf@telefonica.net>
Message-ID: <4A297A92.7030300@laposte.net>


>
> An LLVM program can call any address, valid or not. If the programmer
> figures out the address of one of those "forbidden" functions, he can
> call it. You may write some pass for detecting suspicious constructs and
> reject them, but solving the problem the right way looks very hard or
> impossible to me, mostly because you want to use LLVM code generated by
> a C/C++ compiler.
>   

you may want to take a look at
 http://nativeclient.googlecode.com/svn/trunk/nacl/googleclient/native_client/documentation/nacl_paper.pdf
The paper look promising. I didn't try there implementation
http://code.google.com/p/nativeclient/ . The license is new BSD.
Will it is currently developped for the web, it could be useful for any 
applications which does not trust its plugins.

regards,

Cédric



From gohman at apple.com  Fri Jun  5 13:19:01 2009
From: gohman at apple.com (Dan Gohman)
Date: Fri, 5 Jun 2009 13:19:01 -0700
Subject: [LLVMdev] SSE Scalar Convert Intrinsics
In-Reply-To: <200906051051.16447.dag@cray.com>
References: <200906051051.16447.dag@cray.com>
Message-ID: <2254CD55-DCC0-418B-8172-280AFAD9ECC9@apple.com>


On Jun 5, 2009, at 8:51 AM, David Greene wrote:

> I have a question about the SSE scalar convert intrinsics.
>
> cvtsd2si is defined thusly:
>
>  def int_x86_sse2_cvtsd2si64 :  
> GCCBuiltin<"__builtin_ia32_cvtsd2si64">,
>              Intrinsic<[llvm_i64_ty, llvm_v2f64_ty], [IntrNoMem]>;
>
> This matches the signature of the GCC intrinsic.  The fact that the  
> GCC
> intrinsic has a type mismatch on the input (vector rather than scalar)
> is strange, but ok, we'll run with it.
>
> Until this:
>
> def Int_CVTSD2SIrm : SDI<0x2D, MRMSrcMem, (outs GR32:$dst), (ins  
> f128mem:
> $src),
>                         "cvtsd2si\t{$src, $dst|$dst, $src}",
>                         [(set GR32:$dst, (int_x86_sse2_cvtsd2si
>                                           (load addr:$src)))]>;
>
> Er, this makes us load a 128-bit quantity, which is almost certainly  
> not
> what we want.

Yes, that looks wrong, even if it ends up doing something that
ends up working.

>
>
> Do we need two intrinsics for these scalar converts, one to satisfy  
> the
> (arguably broken) GCC interface and one to really reflect the  
> operation
> as specified by the ISA?

That's what's done for most other instructions, unfortunately.
For cvtsd2si, there's currently no "normal" version in the tree,
but if you add one, it wouldn't be alone.

One thing we'd like to do at some point is have front-ends lower
intrinsics for scalar instructions into
extractelement+op+insertelement, so that we don't need two
versions of each of the instructions.  Doing this for everything
will require some work to make sure that the extra insert/extract
operators don't incur unnecessary copying, but that's also
something we'd like to do regardless.

Dan



From eli.friedman at gmail.com  Fri Jun  5 13:22:31 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Fri, 5 Jun 2009 13:22:31 -0700
Subject: [LLVMdev] SSE Scalar Convert Intrinsics
In-Reply-To: <200906051051.16447.dag@cray.com>
References: <200906051051.16447.dag@cray.com>
Message-ID: <f5aa3e9b0906051322u25fcf2b7h9aa6d889c7ab91c9@mail.gmail.com>

On Fri, Jun 5, 2009 at 8:51 AM, David Greene<dag at cray.com> wrote:
> def Int_CVTSD2SIrm : SDI<0x2D, MRMSrcMem, (outs GR32:$dst), (ins f128mem:
> $src),
>                         "cvtsd2si\t{$src, $dst|$dst, $src}",
>                         [(set GR32:$dst, (int_x86_sse2_cvtsd2si
>                                           (load addr:$src)))]>;
>
> Er, this makes us load a 128-bit quantity, which is almost certainly not
> what we want.

I agree, that doesn't look right.

> Do we need two intrinsics for these scalar converts, one to satisfy the
> (arguably broken) GCC interface and one to really reflect the operation
> as specified by the ISA?

We really need zero intrinsics... it's quite easy to map onto existing
LLVM instructions.  See the definition of CVTSD2SIrm.

-Eli



From natebegeman at me.com  Fri Jun  5 13:33:28 2009
From: natebegeman at me.com (Nate Begeman)
Date: Fri, 05 Jun 2009 13:33:28 -0700
Subject: [LLVMdev] SSE Scalar Convert Intrinsics
In-Reply-To: <2254CD55-DCC0-418B-8172-280AFAD9ECC9@apple.com>
References: <200906051051.16447.dag@cray.com>
	<2254CD55-DCC0-418B-8172-280AFAD9ECC9@apple.com>
Message-ID: <FF8B789B-16CE-452A-AED9-30A1776DF8B2@me.com>


On Jun 5, 2009, at 1:19 PM, Dan Gohman wrote:

>
> On Jun 5, 2009, at 8:51 AM, David Greene wrote:
>
>> I have a question about the SSE scalar convert intrinsics.
>>
>> cvtsd2si is defined thusly:
>>
>> def int_x86_sse2_cvtsd2si64 :
>> GCCBuiltin<"__builtin_ia32_cvtsd2si64">,
>>             Intrinsic<[llvm_i64_ty, llvm_v2f64_ty], [IntrNoMem]>;
>>
>> This matches the signature of the GCC intrinsic.  The fact that the
>> GCC
>> intrinsic has a type mismatch on the input (vector rather than  
>> scalar)
>> is strange, but ok, we'll run with it.
>>
>> Until this:
>>
>> def Int_CVTSD2SIrm : SDI<0x2D, MRMSrcMem, (outs GR32:$dst), (ins
>> f128mem:
>> $src),
>>                        "cvtsd2si\t{$src, $dst|$dst, $src}",
>>                        [(set GR32:$dst, (int_x86_sse2_cvtsd2si
>>                                          (load addr:$src)))]>;
>>
>> Er, this makes us load a 128-bit quantity, which is almost certainly
>> not
>> what we want.
>
> Yes, that looks wrong, even if it ends up doing something that
> ends up working.
>
>>
>>
>> Do we need two intrinsics for these scalar converts, one to satisfy
>> the
>> (arguably broken) GCC interface and one to really reflect the
>> operation
>> as specified by the ISA?
>
> That's what's done for most other instructions, unfortunately.
> For cvtsd2si, there's currently no "normal" version in the tree,
> but if you add one, it wouldn't be alone.
>
> One thing we'd like to do at some point is have front-ends lower
> intrinsics for scalar instructions into
> extractelement+op+insertelement, so that we don't need two
> versions of each of the instructions.  Doing this for everything
> will require some work to make sure that the extra insert/extract
> operators don't incur unnecessary copying, but that's also
> something we'd like to do regardless.

Agreed!

Nate



From mcheva at cs.mcgill.ca  Fri Jun  5 14:15:37 2009
From: mcheva at cs.mcgill.ca (Nyx)
Date: Fri, 5 Jun 2009 14:15:37 -0700 (PDT)
Subject: [LLVMdev]  Int1 to Double Type Conversion
Message-ID: <23895625.post@talk.nabble.com>


Hello,

I would like to know if there is an instruction to convert values from the
Int1 type to the Double type in LLVM. I would like to achieve the equivalent
of casting a bool value to a double value in C++. Doing the simple
CreateSIToFP or CreateUIToFP does not work, it throws an assertion ("invalid
cast"). I simply want to avoid branching it's not necessary. What's the
simplest way to achieve this?

Thank you for your time,

- Max
-- 
View this message in context: http://www.nabble.com/Int1-to-Double-Type-Conversion-tp23895625p23895625.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.



From lhames at gmail.com  Fri Jun  5 14:48:03 2009
From: lhames at gmail.com (Lang Hames)
Date: Fri, 5 Jun 2009 14:48:03 -0700
Subject: [LLVMdev] Removing SimpleRewriter (formerly SimpleSpiller)
In-Reply-To: <200906051055.56245.dag@cray.com>
References: <728927c70906031334l307ba6a0l71a13b10bf7976c8@mail.gmail.com>
	<200906041546.03491.dag@cray.com>
	<728927c70906041703j6b71a16sfb854b1dd258765c@mail.gmail.com>
	<200906051055.56245.dag@cray.com>
Message-ID: <728927c70906051448q6894cf27k8d2a1bf5552d8fd4@mail.gmail.com>

> One thing I would recommend is that the code that does IR
> changes be separated from the code (if any) that does dataflow
> information updates.  The entanglement of these two functions
> is part of the reason that the coalescing code is so complicated.
> Separating the actions allows the code to be reused by other
> passes (different register allocators, for example).

The new framework will definitely be doing both IR modifications and
liveness info updates. Keeping these concerns separate is a good idea,
and I'll do my best, however the primary goal at the moment is
incremental improvement of the current scheme.

- Lang.



From eli.friedman at gmail.com  Fri Jun  5 15:08:02 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Fri, 5 Jun 2009 15:08:02 -0700
Subject: [LLVMdev] Int1 to Double Type Conversion
In-Reply-To: <23895625.post@talk.nabble.com>
References: <23895625.post@talk.nabble.com>
Message-ID: <f5aa3e9b0906051508y52b51684k3251afbc1c7fdd5c@mail.gmail.com>

On Fri, Jun 5, 2009 at 2:15 PM, Nyx<mcheva at cs.mcgill.ca> wrote:
>
> Hello,
>
> I would like to know if there is an instruction to convert values from the
> Int1 type to the Double type in LLVM. I would like to achieve the equivalent
> of casting a bool value to a double value in C++. Doing the simple
> CreateSIToFP or CreateUIToFP does not work, it throws an assertion ("invalid
> cast"). I simply want to avoid branching it's not necessary. What's the
> simplest way to achieve this?

The following LLVM assembly seems to compile just fine:
define double @a(i1 zeroext %x) nounwind {
%rval = uitofp i1 %x to double
ret double %rval
}

What does your code look like?

-Eli


From dag at cray.com  Fri Jun  5 15:16:31 2009
From: dag at cray.com (David Greene)
Date: Fri, 5 Jun 2009 17:16:31 -0500
Subject: [LLVMdev] SSE Scalar Convert Intrinsics
In-Reply-To: <2254CD55-DCC0-418B-8172-280AFAD9ECC9@apple.com>
References: <200906051051.16447.dag@cray.com>
	<2254CD55-DCC0-418B-8172-280AFAD9ECC9@apple.com>
Message-ID: <200906051716.32029.dag@cray.com>

On Friday 05 June 2009 15:19, Dan Gohman wrote:

> > Do we need two intrinsics for these scalar converts, one to satisfy
> > the
> > (arguably broken) GCC interface and one to really reflect the
> > operation
> > as specified by the ISA?
>
> That's what's done for most other instructions, unfortunately.
> For cvtsd2si, there's currently no "normal" version in the tree,
> but if you add one, it wouldn't be alone.

Ok.

> One thing we'd like to do at some point is have front-ends lower
> intrinsics for scalar instructions into
> extractelement+op+insertelement, so that we don't need two
> versions of each of the instructions.  Doing this for everything
> will require some work to make sure that the extra insert/extract
> operators don't incur unnecessary copying, but that's also
> something we'd like to do regardless.

So then how does one do a memop intrinsic?  Does it mean we can't
match to the memop versions of instructions?

                             -Dave


From dag at cray.com  Fri Jun  5 15:19:03 2009
From: dag at cray.com (David Greene)
Date: Fri, 5 Jun 2009 17:19:03 -0500
Subject: [LLVMdev] SSE Scalar Convert Intrinsics
In-Reply-To: <f5aa3e9b0906051322u25fcf2b7h9aa6d889c7ab91c9@mail.gmail.com>
References: <200906051051.16447.dag@cray.com>
	<f5aa3e9b0906051322u25fcf2b7h9aa6d889c7ab91c9@mail.gmail.com>
Message-ID: <200906051719.03554.dag@cray.com>

On Friday 05 June 2009 15:22, Eli Friedman wrote:

> > Do we need two intrinsics for these scalar converts, one to satisfy the
> > (arguably broken) GCC interface and one to really reflect the operation
> > as specified by the ISA?
>
> We really need zero intrinsics... it's quite easy to map onto existing
> LLVM instructions.  See the definition of CVTSD2SIrm.

In some cases, yes.  But not all of the X86 instructions are accessible
through LLVM IR.  And sometimes we like the ability to have our frontend
lower to intrinsics so we know EXACTLY what code will come out the other
end.

And see my previous post about sint_to_fp with a memory operand not working
in TableGen ("TableGen Type Inference").  I'll be debugging that next week,
probably.

                               -Dave


From gohman at apple.com  Fri Jun  5 15:41:39 2009
From: gohman at apple.com (Dan Gohman)
Date: Fri, 5 Jun 2009 15:41:39 -0700
Subject: [LLVMdev] TableGen Type Inference
In-Reply-To: <200906041506.03863.dag@cray.com>
References: <200906041506.03863.dag@cray.com>
Message-ID: <12E55858-518D-4CBF-A4B7-66B9EB254837@apple.com>

How is bc_memopv4i32 defined?  The bitconvert in the tablegen
output is marked isInt, which means it's the node that didn't get
inferred.

Dan

On Jun 4, 2009, at 1:06 PM, David Greene wrote:

> Can someone explain why TableGen can't figure this out?
>
> VCVTDQ2PS128rm: 	(set:isVoid VR128:v4f32:$dst, (sint_to_fp:v4f32
> (bitconvert:isInt (ld:v4i32 addr:iPTR:$src)<<P:Predicate_memop>>)))
> llvm/tblgen: In VCVTDQ2PS128rm: Could not infer all types in pattern!
>
> The pattern as written looks like this:
>
> [(set VR128:$dst, (v4f32 (sint_to_fp (bc_memopv4i32 addr:$src))))]
>
> I'm trying to unify AVX/SSE converts in a reasonable way.  Right now,
> X86InstrSSE.td doesn't have patterns for sint_to_fp and fp_to_sint
> with memory operands.  I guess this is why, but I don't understand
> why it's illegal.
>
>                                 -Dave
> _______________________________________________
> 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  Fri Jun  5 15:41:42 2009
From: gohman at apple.com (Dan Gohman)
Date: Fri, 5 Jun 2009 15:41:42 -0700
Subject: [LLVMdev] SSE Scalar Convert Intrinsics
In-Reply-To: <200906051716.32029.dag@cray.com>
References: <200906051051.16447.dag@cray.com>
	<2254CD55-DCC0-418B-8172-280AFAD9ECC9@apple.com>
	<200906051716.32029.dag@cray.com>
Message-ID: <19687584-7EA9-4B5C-8656-D22986F81C37@apple.com>


On Jun 5, 2009, at 3:16 PM, David Greene wrote:

> On Friday 05 June 2009 15:19, Dan Gohman wrote:
>
>> One thing we'd like to do at some point is have front-ends lower
>> intrinsics for scalar instructions into
>> extractelement+op+insertelement, so that we don't need two
>> versions of each of the instructions.  Doing this for everything
>> will require some work to make sure that the extra insert/extract
>> operators don't incur unnecessary copying, but that's also
>> something we'd like to do regardless.
>
> So then how does one do a memop intrinsic?  Does it mean we can't
> match to the memop versions of instructions?

Memory operands would be lowered to explicit loads and stores,
which would be pattern-matched into memop instructions by
instruction selection.

Dan



From eli.friedman at gmail.com  Fri Jun  5 15:48:34 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Fri, 5 Jun 2009 15:48:34 -0700
Subject: [LLVMdev] SSE Scalar Convert Intrinsics
In-Reply-To: <200906051719.03554.dag@cray.com>
References: <200906051051.16447.dag@cray.com>
	<f5aa3e9b0906051322u25fcf2b7h9aa6d889c7ab91c9@mail.gmail.com>
	<200906051719.03554.dag@cray.com>
Message-ID: <f5aa3e9b0906051548x315b2b3ek13bd0580693dbcc9@mail.gmail.com>

On Fri, Jun 5, 2009 at 3:19 PM, David Greene<dag at cray.com> wrote:
> On Friday 05 June 2009 15:22, Eli Friedman wrote:
>
>> > Do we need two intrinsics for these scalar converts, one to satisfy the
>> > (arguably broken) GCC interface and one to really reflect the operation
>> > as specified by the ISA?
>>
>> We really need zero intrinsics... it's quite easy to map onto existing
>> LLVM instructions.  See the definition of CVTSD2SIrm.
>
> In some cases, yes.  But not all of the X86 instructions are accessible
> through LLVM IR.

Like this one :)  Sorry, I was confusing it with CVTTSD2SIrm.

-Eli



From dag at cray.com  Fri Jun  5 16:04:45 2009
From: dag at cray.com (David Greene)
Date: Fri, 5 Jun 2009 18:04:45 -0500
Subject: [LLVMdev] TableGen Type Inference
In-Reply-To: <12E55858-518D-4CBF-A4B7-66B9EB254837@apple.com>
References: <200906041506.03863.dag@cray.com>
	<12E55858-518D-4CBF-A4B7-66B9EB254837@apple.com>
Message-ID: <200906051804.45772.dag@cray.com>

On Friday 05 June 2009 17:41, Dan Gohman wrote:
> How is bc_memopv4i32 defined?  The bitconvert in the tablegen
> output is marked isInt, which means it's the node that didn't get
> inferred.

def bc_memopv4i32 : PatFrag<(ops node:$ptr), (bitconvert 
                                             (memopv4i32 node:$ptr))>;

                              -Dave


From dag at cray.com  Fri Jun  5 16:05:35 2009
From: dag at cray.com (David Greene)
Date: Fri, 5 Jun 2009 18:05:35 -0500
Subject: [LLVMdev] SSE Scalar Convert Intrinsics
In-Reply-To: <19687584-7EA9-4B5C-8656-D22986F81C37@apple.com>
References: <200906051051.16447.dag@cray.com> <200906051716.32029.dag@cray.com>
	<19687584-7EA9-4B5C-8656-D22986F81C37@apple.com>
Message-ID: <200906051805.35328.dag@cray.com>

On Friday 05 June 2009 17:41, Dan Gohman wrote:
> On Jun 5, 2009, at 3:16 PM, David Greene wrote:
> > On Friday 05 June 2009 15:19, Dan Gohman wrote:
> >> One thing we'd like to do at some point is have front-ends lower
> >> intrinsics for scalar instructions into
> >> extractelement+op+insertelement, so that we don't need two
> >> versions of each of the instructions.  Doing this for everything
> >> will require some work to make sure that the extra insert/extract
> >> operators don't incur unnecessary copying, but that's also
> >> something we'd like to do regardless.
> >
> > So then how does one do a memop intrinsic?  Does it mean we can't
> > match to the memop versions of instructions?
>
> Memory operands would be lowered to explicit loads and stores,
> which would be pattern-matched into memop instructions by
> instruction selection.

Ok, that'd be cool.  :)

                             -Dave


From dag at cray.com  Fri Jun  5 16:06:43 2009
From: dag at cray.com (David Greene)
Date: Fri, 5 Jun 2009 18:06:43 -0500
Subject: [LLVMdev] SSE Scalar Convert Intrinsics
In-Reply-To: <f5aa3e9b0906051548x315b2b3ek13bd0580693dbcc9@mail.gmail.com>
References: <200906051051.16447.dag@cray.com> <200906051719.03554.dag@cray.com>
	<f5aa3e9b0906051548x315b2b3ek13bd0580693dbcc9@mail.gmail.com>
Message-ID: <200906051806.43537.dag@cray.com>

On Friday 05 June 2009 17:48, Eli Friedman wrote:

> > In some cases, yes.  But not all of the X86 instructions are accessible
> > through LLVM IR.
>
> Like this one :)  Sorry, I was confusing it with CVTTSD2SIrm.

It happens.  :)

Stupid Intel mnemonics...

                             -Dave



From foldr at codedgers.com  Fri Jun  5 18:15:35 2009
From: foldr at codedgers.com (Mikhail Glushenkov)
Date: Sat, 6 Jun 2009 01:15:35 +0000 (UTC)
Subject: [LLVMdev] llvmc for PIC16
References: <4A2633E9.4070207@microchip.com>
	<loom.20090604T142600-116@post.gmane.org>
	<4A28C062.9060307@microchip.com>
Message-ID: <loom.20090606T011159-60@post.gmane.org>

Hi Sanjiv,

Sanjiv Gupta <sanjiv.gupta <at> microchip.com> writes:

> The salient features that we want to have in the driver are:
> [...]
> 
> Is this achievable by a tablegen based driver ?

Yes - in fact, I think I'll just write a basic mcc16 driver myself over this
weekend - it'll make a great addition to the examples and a nice starting point
for you to work on.





From eli.friedman at gmail.com  Fri Jun  5 18:42:16 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Fri, 5 Jun 2009 18:42:16 -0700
Subject: [LLVMdev] TableGen Type Inference
In-Reply-To: <200906051804.45772.dag@cray.com>
References: <200906041506.03863.dag@cray.com>
	<12E55858-518D-4CBF-A4B7-66B9EB254837@apple.com>
	<200906051804.45772.dag@cray.com>
Message-ID: <f5aa3e9b0906051842o5abd7c96g332c9ad981e45d68@mail.gmail.com>

On Fri, Jun 5, 2009 at 4:04 PM, David Greene<dag at cray.com> wrote:
> On Friday 05 June 2009 17:41, Dan Gohman wrote:
>> How is bc_memopv4i32 defined?  The bitconvert in the tablegen
>> output is marked isInt, which means it's the node that didn't get
>> inferred.
>
> def bc_memopv4i32 : PatFrag<(ops node:$ptr), (bitconvert
>                                             (memopv4i32 node:$ptr))>;

That would explain it: it isn't clever enough to deduce the type of
the bitconvert, so you'll have to write something like the following:

[(set VR128:$dst, (v4f32 (sint_to_fp (v4i32 (bc_memopv4i32 addr:$src)))))]

-Eli



From me22.ca at gmail.com  Fri Jun  5 19:51:36 2009
From: me22.ca at gmail.com (me22)
Date: Fri, 5 Jun 2009 19:51:36 -0700
Subject: [LLVMdev] Creating a LLVM Project from the Sample project
In-Reply-To: <de35c4ed0906050249x3bf76601m44ef5fdbe1381d0e@mail.gmail.com>
References: <de35c4ed0906050249x3bf76601m44ef5fdbe1381d0e@mail.gmail.com>
Message-ID: <fa28b9250906051951wb9758djbb9423505547b8c6@mail.gmail.com>

2009/6/5 Camille Troillard <camille at osculator.net>:
>
> I have followed the steps described in http://llvm.org/docs/Projects.html.
> It seems there is a problem with the AutoRegen.sh script.
>

I'm not sure anyone actually uses that -- the bug about it seems to be
ignored: http://llvm.org/bugs/show_bug.cgi?id=1220

Perhaps if you add your findings to it it might get noticed?


From foldr at codedgers.com  Fri Jun  5 20:11:24 2009
From: foldr at codedgers.com (Mikhail Glushenkov)
Date: Sat, 6 Jun 2009 03:11:24 +0000 (UTC)
Subject: [LLVMdev] make check hanging in hello.c?
References: <ee2e06e90906040154y119af077l7c59891e7c5cc442@mail.gmail.com>
Message-ID: <loom.20090606T031028-456@post.gmane.org>

Hi Jay,

Jay Foad <jay.foad <at> gmail.com> writes:

> 
> On an ENABLE_OPTIMIZED=1 build, "make check" hangs for me here:
> 
> Running /home/foad/svn/llvm-project/llvm/trunk/test/LLVMC/llvmc.exp ...

Couldn't reproduce this on my machine.






From varonrotem at gmail.com  Sat Jun  6 01:12:12 2009
From: varonrotem at gmail.com (Rotem Varon)
Date: Sat, 6 Jun 2009 04:12:12 -0400
Subject: [LLVMdev] LiveValues Pass
In-Reply-To: <87892836-C3D5-4044-9D28-0561A3F54F20@apple.com>
References: <4f5edbea0906020554h6f8d6fbfp3ea5d2e74b8077@mail.gmail.com>
	<87892836-C3D5-4044-9D28-0561A3F54F20@apple.com>
Message-ID: <4f5edbea0906060112p351659a1l6538c057eb44223f@mail.gmail.com>

Hi,

I tried to use the LiveValues pass without success.
I did exactly as you wrote me but no luck for me.
I am getting this error :

[rotem at localhost ~]$ opt -load
/home/rotem/Desktop/install/Release/lib/BBPass.so -BBPass <
/home/rotem/Desktop/tmp/BBtry.bc > /dev/null
Error opening '/home/rotem/Desktop/install/Release/lib/BBPass.so':
/home/rotem/Desktop/install/Release/lib/BBPass.so: undefined symbol:
_ZN4llvm10LiveValues2IDE
  -load request ignored.
opt: Unknown command line argument '-BBPass'.  Try: 'opt --help'

I tried also to relocate the LiveValues to the same directory of me pass.
This is the error:

llvm[0]: Compiling BBPass.cpp for Release build  (PIC)
llvm[0]: Compiling LiveValues.cpp for Release build  (PIC)
LiveValues.cpp: In member function 'llvm::LiveValues::Memo&
llvm::LiveValues::compute(const llvm::Value*)':
LiveValues.cpp:150: error: 'const class llvm::PHINode' has no member named
'getIncomingValueNumForOperand'

I really need your help here
Thank you.





On Tue, Jun 2, 2009 at 2:10 PM, Dan Gohman <gohman at apple.com> wrote:

>
> On Jun 2, 2009, at 5:54 AM, Rotem Varon wrote:
> >
> > This questions are on the LiveValues pass:
> > Do i need to set the "LiveValues" pass in the PassManager as a
> > prerequisite? if so how do i get the results ?
>
> Yes; it's a standard analysis pass. See
> http://llvm.org/docs/WritingAnLLVMPass.html
> for information about interactions between passes.
>
> > How do i get/use the results of LiveValuse pass in my pass?
> > Is there documentation in the LLVM site (beside of the comments on
> > the file)?
> > Can i simply use its public function ?
>
> There are Doxygen comments which can be read either in the file itself
> or via http://llvm.org/doxygen/
>
> 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.llvm.org/pipermail/llvm-dev/attachments/20090606/5a99089a/attachment.html>

From camille at osculator.net  Sat Jun  6 01:30:23 2009
From: camille at osculator.net (Camille Troillard)
Date: Sat, 6 Jun 2009 10:30:23 +0200
Subject: [LLVMdev] Creating a LLVM Project from the Sample project
In-Reply-To: <fa28b9250906051951wb9758djbb9423505547b8c6@mail.gmail.com>
References: <de35c4ed0906050249x3bf76601m44ef5fdbe1381d0e@mail.gmail.com>
	<fa28b9250906051951wb9758djbb9423505547b8c6@mail.gmail.com>
Message-ID: <de35c4ed0906060130m22fc794mf6a39073a1267db0@mail.gmail.com>

On Sat, Jun 6, 2009 at 4:51 AM, me22<me22.ca at gmail.com> wrote:
>
> I'm not sure anyone actually uses that -- the bug about it seems to be
> ignored: http://llvm.org/bugs/show_bug.cgi?id=1220
>
> Perhaps if you add your findings to it it might get noticed?

Thanks Scott, I think it was the same bug.
I am using Xcode now, though :-(
For those who are interested, here is a Xcode build configuration file
for those who would like to build their project against LLVM.  It was
inspired from what I found in clang.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-tool.xcconfig
Type: application/octet-stream
Size: 1307 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090606/7c97fa57/attachment.obj>

From jay.foad at gmail.com  Sat Jun  6 04:53:30 2009
From: jay.foad at gmail.com (Jay Foad)
Date: Sat, 6 Jun 2009 12:53:30 +0100
Subject: [LLVMdev] make check hanging in hello.c?
In-Reply-To: <loom.20090606T031028-456@post.gmane.org>
References: <ee2e06e90906040154y119af077l7c59891e7c5cc442@mail.gmail.com>
	<loom.20090606T031028-456@post.gmane.org>
Message-ID: <ee2e06e90906060453g751cfa3j1478b7f7d70fbe26@mail.gmail.com>

>> On an ENABLE_OPTIMIZED=1 build, "make check" hangs for me here:
>>
>> Running /home/foad/svn/llvm-project/llvm/trunk/test/LLVMC/llvmc.exp ...
>
> Couldn't reproduce this on my machine.

It stopped happening here too. Thanks for checking though!

Thanks,
Jay.


From mcheva at cs.mcgill.ca  Sat Jun  6 07:33:22 2009
From: mcheva at cs.mcgill.ca (Nyx)
Date: Sat, 6 Jun 2009 07:33:22 -0700 (PDT)
Subject: [LLVMdev] Int1 to Double Type Conversion
In-Reply-To: <f5aa3e9b0906051508y52b51684k3251afbc1c7fdd5c@mail.gmail.com>
References: <23895625.post@talk.nabble.com>
	<f5aa3e9b0906051508y52b51684k3251afbc1c7fdd5c@mail.gmail.com>
Message-ID: <23902249.post@talk.nabble.com>


I'm simply using the IRBuilder, I call CreateUIToFP with the current value
(llvm::Type::Int1Ty type), and pass the llvm::Type::DoubleTy as the
destination type. This fails.

I notice that your assembly has "zeroext" in the function parameter. Perhaps
I need to create a "ZExt" instruction to extend the Int1 to an Int32 or
something?
-- 
View this message in context: http://www.nabble.com/Int1-to-Double-Type-Conversion-tp23895625p23902249.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.



From varonrotem at gmail.com  Sat Jun  6 08:38:15 2009
From: varonrotem at gmail.com (Rotem Varon)
Date: Sat, 6 Jun 2009 11:38:15 -0400
Subject: [LLVMdev] addRequired(), Loop Unrolling
Message-ID: <4f5edbea0906060838v3689dadbs5abf0766533c983a@mail.gmail.com>

Hi,

I am trying to set loop unrolling as a required pass.
AU.addRequired<LoopUnroll>();

should I include any header file?
How can I be possessive that "LoopUnroll" is the name I need ?

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090606/aaab7bd1/attachment.html>

From hc2428 at columbia.edu  Sat Jun  6 08:56:12 2009
From: hc2428 at columbia.edu (hc2428 at columbia.edu)
Date: Sat, 06 Jun 2009 11:56:12 -0400
Subject: [LLVMdev] Can llvm-2.5 work with "-O1 -g"?
In-Reply-To: <4f5edbea0906060838v3689dadbs5abf0766533c983a@mail.gmail.com>
References: <4f5edbea0906060838v3689dadbs5abf0766533c983a@mail.gmail.com>
Message-ID: <20090606115612.v5tk8rpy1hc088w8@cubmail.cc.columbia.edu>

Dear staff,

     I need to get the line number and file name information of the  
source code for each instruction in *.bc file. I find that llvm-2.4  
can not support "-O1 -g", which means if we are at O1 to O3  
optimization level, we can not get any dbg.stoppoint inserted into the  
LLVM IR.

     However, our project requires us to get the line number and file  
name information of the source code for each instruction in *.bc file  
at any Ox level. I have built and run llvm-2.5 and found that it still  
can not support "-Ox -g".

     If we are not using "-g", do we have other ways to get the line  
number and file name information for each instruction in *.bc file?

Best,
Heming


From keveman at gmail.com  Sat Jun  6 09:47:08 2009
From: keveman at gmail.com (Manjunath Kudlur)
Date: Sat, 6 Jun 2009 09:47:08 -0700
Subject: [LLVMdev] Tablegen question
Message-ID: <68c4c3e20906060947h7cc89277uf41a0d8c9ffabe89@mail.gmail.com>

I want to add a set of "properties" to each instruction in my
instruction set, and want to be able to query that in my
machine-specific optimizations. My Insts.td file looks as follows :

class InstProperty;

def propX : InstProperty;
def propY : InstProperty;
def propZ : InstProperty;

class myInst<..., list<InstProperty> props> : Instruction {
  ...
  ...
  list<InstProperty> Properties=props;
}

def i1 : myInst<..., [propX]>;
def i2 : myInst<..., [propX, propZ]>;
def i3 : myInst<..., []>;

I want to add a Tablegen backend that would look for Instructions
derived from myInst, look for Properties field, and output a
opcode->bitfield map as follows:

PropMap[myInst::i1] = propX;
PropMap[myInst::i2] = propX | propZ;
PropMap[myInst::i3] = 0;

where propX,propY,and propZ will be defined as appropriate enums.
Now, I looked at the current Tablegen backends, and I didn't find any
that are specific to a particular architecture backend, say, to X86 or
Sparc etc.. That got me wondering if I am breaking some conventions
and not doing things in the LLVM-way. Is what I am trying to do an
intended use case for Tablegen? Why aren't there Tablegen backends
specific to some architecture backends? I would be grateful for any
advice from the community.

Manjunath


From vadve at cs.uiuc.edu  Sat Jun  6 11:31:11 2009
From: vadve at cs.uiuc.edu (Vikram S. Adve)
Date: Sat, 6 Jun 2009 13:31:11 -0500
Subject: [LLVMdev] SSI and ABCD for LLVM
In-Reply-To: <4a292afe.04015a0a.5436.2327@mx.google.com>
References: <4A27D078.807@dcc.ufmg.br> <4A28170A.3020204@lip6.fr>
	<1244161343.3936.1.camel@haohui-laptop>	<4A2875E3.9070706@dcc.ufmg.br>
	<4a292afe.04015a0a.5436.2327@mx.google.com>
Message-ID: <16517D08-D112-4764-9FE6-91B37DE26857@cs.uiuc.edu>

On Jun 5, 2009, at 9:26 AM, Mai, Haohui wrote:

> By static array bounds checking, I mean eliminating array bounds  
> checking
> which can be proved ``safe'' at compile-time.

Even though SAFECode does have such a pass, there are some tradeoffs  
with the current version:

1. It uses an external solver (Omega), which is one more dependence  
for LLVM in general.  I don't have a problem with this myself but some  
users may.

2. The existing algorithm for propagating constraints (inequalities)  
on variables is interprocedural (good) and inefficient (bad).

ABCD has different tradeoffs.  IIRC, ABCD doesn't use an external  
solver, though only because it only handles simple sets of  
inequalities.  The original ABCD algorithm is also intraprocedural,  
which seems extremely limiting in practice.  Is there any plan of  
extending this to work interprocedurally?

--Vikram
Associate Professor, Computer Science
University of Illinois at Urbana-Champaign
http://llvm.org/~vadve




From vadve at cs.uiuc.edu  Sat Jun  6 11:41:44 2009
From: vadve at cs.uiuc.edu (Vikram S. Adve)
Date: Sat, 6 Jun 2009 13:41:44 -0500
Subject: [LLVMdev] How to stop
In-Reply-To: <CA2A3D1D-73DA-4F1F-9495-F55B23889FFB@gmail.com>
References: <CA2A3D1D-73DA-4F1F-9495-F55B23889FFB@gmail.com>
Message-ID: <B412AAFE-F531-40A0-88A1-2319465B37CF@cs.uiuc.edu>

There are 3 parts to what you are looking for, I think:

1) Isolating the driver from your application so that it cannot crash  
your app;

2) Preventing the driver from calling prohibited functions; and

3) Being able to use the same driver binary on all(?) OS'es and  
processor architectures.

LLVM itself cannot give you #3: you need to put many restrictions on  
the source program (e.g., limiting system headers; limiting pointer- 
integer conversions, etc.) to achieve that.

SAFECode (our project) gives you #1 and #2 if you can recompile the  
driver code along with the application.  If you're willing to adding  
some restrictions, you might be able to get those benefits compiling  
the driver alone but I'd have to think about it.

--Vikram
Associate Professor, Computer Science
University of Illinois at Urbana-Champaign
http://llvm.org/~vadve



On Jun 5, 2009, at 7:30 AM, Marcus Zetterquist wrote:

> Hi!
>
>
> Today we use Lua to let 3rd party developers add driver-like modules
> to our application.
>
> The advantages to using Lua compared to DLL:s etc. are that:
>
> 1) the same driver binary can be used on all OS:es and processor
> architectures etc.
>
> 2) We can provide a small API to the Lua drivers and they _cannot_
> call any other external functions.
>
> 3) A buggy driver cannot crash our application. (Almost true  
> statement.)
>
>
> I'm looking into using LLVM and the bitcode format for this instead.
> The additional, very important advantages are:
>
> 4) 3rd parties can port existing (huge amounts of) C / C++ code much
> easier - no need to rewrite all code in Lua.
>
> 5) Performance. We will use the LLVM JIT.
>
>
> Problem: I can't figure out how to do (2) with the LLVM JIT.
>
> It is very important that the driver does not have access to any other
> function in the application except those I provide. It's not OK for
> our application to abort if a driver calls an undefined function - I
> want to just disable _that driver_ in that event.
>
> I can use DisableSymbolSearching() but that causes application to
> abort for unknown symbols.
>
>
> Please advice!
>
>
> /Marcus
>
> _______________________________________________
> 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  Sat Jun  6 13:51:13 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Sat, 06 Jun 2009 13:51:13 -0700
Subject: [LLVMdev] patch for llc/ARM: added mechanism to move switch
 tables from .text -> .data; also cleanup and documentation
In-Reply-To: <8e3491100906021826p4530f341xbb168d260c21342e@mail.gmail.com>
References: <8e3491100906021826p4530f341xbb168d260c21342e@mail.gmail.com>
Message-ID: <0453D1AB-FA5D-4947-BE50-02223AB8955B@apple.com>

+cl::opt<std::string> FlagJumpTableSection("jumptable-section",
+                                           cl::init(".data.jtab"));
+

Is this necessary? Why not just put it in the normal data section?

Also "outline" jumptable seems like a strange term. Can you think of  
something else?

Thanks,

Evan

Sent from my iPhone

On Jun 2, 2009, at 6:26 PM, robert muth <robert at muth.org> wrote:

> Hi:
>
> This is my first patch submission. Hopefully, this is the proper the  
> protocol.
> Attached is a patch for the llc ARM backend:
>
> Added mechanism to generate switch table in a data section
> rather than having it interleaved with the code.
> This is controlled by command line flags and off by default.
> Also, tried to document and improve the code where I modified it.
>
> Robert
> <llc.patch.txt>
> _______________________________________________
> 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.llvm.org/pipermail/llvm-dev/attachments/20090606/bbfb602d/attachment.html>

From nicholas at mxc.ca  Sat Jun  6 18:32:10 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Sat, 06 Jun 2009 18:32:10 -0700
Subject: [LLVMdev] reading untrusted bitcode
Message-ID: <4A2B189A.10307@mxc.ca>

Suppose I had a program that would receive bitcode and do something with 
it other than run it, and for performance I this program is built 
Release-Asserts.

Currently, illegal types are caught by the AsmParser and again by some 
assertions in Type.cpp. However, a .bc file could contain an illegal 
type like [5 x void] and without assertions enabled, this actually gets 
created in the IR. Also, the verifier doesn't check for these, assuming 
that illegal types must have come in through the C++ API.

Whose responsibility is it supposed to be to check types for legality? 
The BCReader? Or perhaps the verifier?

Nick



From eli.friedman at gmail.com  Sat Jun  6 21:31:31 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Sat, 6 Jun 2009 21:31:31 -0700
Subject: [LLVMdev] reading untrusted bitcode
In-Reply-To: <4A2B189A.10307@mxc.ca>
References: <4A2B189A.10307@mxc.ca>
Message-ID: <f5aa3e9b0906062131u3e4b16d2g1d8046d3bb288d53@mail.gmail.com>

On Sat, Jun 6, 2009 at 6:32 PM, Nick Lewycky<nicholas at mxc.ca> wrote:
> Whose responsibility is it supposed to be to check types for legality?
> The BCReader? Or perhaps the verifier?

It's pretty easy to resolve using the rule "assertions should never
trigger": if the bitcode reader triggers an assertion, it's a bug in
the bitcode reader.

-Eli


From nicholas at mxc.ca  Sat Jun  6 22:17:37 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Sat, 06 Jun 2009 22:17:37 -0700
Subject: [LLVMdev] reading untrusted bitcode
In-Reply-To: <f5aa3e9b0906062131u3e4b16d2g1d8046d3bb288d53@mail.gmail.com>
References: <4A2B189A.10307@mxc.ca>
	<f5aa3e9b0906062131u3e4b16d2g1d8046d3bb288d53@mail.gmail.com>
Message-ID: <4A2B4D71.9030607@mxc.ca>

Eli Friedman wrote:
> On Sat, Jun 6, 2009 at 6:32 PM, Nick Lewycky<nicholas at mxc.ca> wrote:
>> Whose responsibility is it supposed to be to check types for legality?
>> The BCReader? Or perhaps the verifier?
> 
> It's pretty easy to resolve using the rule "assertions should never
> trigger": if the bitcode reader triggers an assertion, it's a bug in
> the bitcode reader.

And now, arguments for the other side:

   1. Reading untrusted bytecode is a theoretical use case (I don't know 
of anyone who does it and I'm not planning to either) and bytecode 
reader performance is critical for your LTO times (which is a real use 
case and one I do care about).
   2. If you put it in the verifier instead you can detect errors from 
direct C++ API users as well.

Do you want to keep your position or switch? ;-)

Nick



From foldr at codedgers.com  Sun Jun  7 00:19:40 2009
From: foldr at codedgers.com (Mikhail Glushenkov)
Date: Sun, 7 Jun 2009 07:19:40 +0000 (UTC)
Subject: [LLVMdev] llvmc for PIC16
References: <4A2633E9.4070207@microchip.com>
	<loom.20090604T142600-116@post.gmane.org>
	<4A28C062.9060307@microchip.com>
Message-ID: <loom.20090607T070933-452@post.gmane.org>

Hi Sanjiv,

Sanjiv Gupta <sanjiv.gupta <at> microchip.com> writes:

> The salient features that we want to have in the driver are:
> [...]

As promised, I've implemented a basic compiler driver for the
PIC16 toolchain. It's under tools/llvmc/examples/mcc16.

Some examples illustrating the features you requested:  

> 2. If the user has specified to generate the final executable, then 
> llvm-ld should run on all the .bc files generated by clang and create a 
> single optimized .bc file for further tools.

$ mcc16 -dry-run foo.c bar.c
clang-cc foo.c -o /tmp/llvm_6ibgr9/foo.bc 
clang-cc bar.c -o /tmp/llvm_6ibgr9/bar.bc 
llvm-ld /tmp/llvm_6ibgr9/foo.bc /tmp/llvm_6ibgr9/bar.bc \
    -o /tmp/llvm_6ibgr9/tmp.bc 
llc -f /tmp/llvm_6ibgr9/tmp.bc -o /tmp/llvm_6ibgr9/tmp.s 
native-as /tmp/llvm_6ibgr9/tmp.s -o /tmp/llvm_6ibgr9/tmp.o 
native-ld /tmp/llvm_6ibgr9/tmp.o -o a.out 

> 3. -Wo <options> - pass optimizations to the llvm-ld
> 4. mcc16 -Wl <options> - pass options to native linker.
> 5. mcc16 -Wa <options> - pass options to native assembler.

$ mcc16 -dry-run -Wo,-opt1 -Wllc,-opt2 -Wa,-opt3 -Wl,-opt4 foo.c
clang-cc foo.c -o /tmp/llvm_92HLCj/foo.bc 
llvm-ld -opt1 /tmp/llvm_92HLCj/foo.bc -o /tmp/llvm_92HLCj/tmp.bc 
llc -opt2 -f /tmp/llvm_92HLCj/tmp.bc -o /tmp/llvm_92HLCj/tmp.s 
native-as -opt3 /tmp/llvm_92HLCj/tmp.s -o /tmp/llvm_92HLCj/tmp.o 
native-ld -opt4 /tmp/llvm_92HLCj/tmp.o -o a.out 
 
> $ mcc16 -S foo.c

$ mcc16 -dry-run -S foo.c
clang-cc foo.c -o /tmp/llvm_0uiDCR/foo.bc 
llvm-ld /tmp/llvm_0uiDCR/foo.bc -o /tmp/llvm_0uiDCR/foo.bc 
llc -f /tmp/llvm_0uiDCR/foo.bc -o foo.s 

> $ mcc16 -S foo.c bar.c

$ mcc16 -dry-run -S foo.c bar.c
clang-cc foo.c -o /tmp/llvm_1zAqik/foo.bc 
llvm-ld /tmp/llvm_1zAqik/foo.bc -o /tmp/llvm_1zAqik/foo.bc 
llc -f /tmp/llvm_1zAqik/foo.bc -o foo.s 
clang-cc bar.c -o /tmp/llvm_1zAqik/bar.bc 
llvm-ld /tmp/llvm_1zAqik/bar.bc -o /tmp/llvm_1zAqik/bar.bc 
llc -f /tmp/llvm_1zAqik/bar.bc -o bar.s 

> ** Use of -g causes llvm-ld to run with -disable-opt
> $ mcc16 -S -g foo.c

$ mcc16 -dry-run -S -g foo.c   
clang-cc foo.c -o /tmp/llvm_oQFmVn/foo.bc 
llvm-ld -disable-opt /tmp/llvm_oQFmVn/foo.bc -o /tmp/llvm_oQFmVn/foo.bc 
llc -f /tmp/llvm_oQFmVn/foo.bc -o foo.s 

> ** -I is passed to clang-cc, -pre-RA-sched=list-burr to llc.
> $ mcc16 -S -g -I ../include -pre-RA-sched=list-burr foo.c

$ mcc16 -dry-run -S -g -I ../include -pre-RA-sched=list-burr foo.c
clang-cc -I ../include foo.c -o /tmp/llvm_5VxNFQ/foo.bc 
llvm-ld -disable-opt /tmp/llvm_5VxNFQ/foo.bc -o /tmp/llvm_5VxNFQ/foo.bc 
llc -pre-RA-sched list-burr -f /tmp/llvm_5VxNFQ/foo.bc -o foo.s 

This should be enough to get you started. 

I'm always happy to answer any further questions you may have. If
you want to e-mail me privately, please use the.dead.shall.rise
<at_sign> gmail dot com for now (our provider problems weren't
resolved yet).



From llvm at assumetheposition.nl  Sun Jun  7 01:48:30 2009
From: llvm at assumetheposition.nl (Paul Melis)
Date: Sun, 07 Jun 2009 10:48:30 +0200
Subject: [LLVMdev] Programmatically setting command line options?
Message-ID: <4A2B7EDE.9020501@assumetheposition.nl>

Hello,

Is there currently a way to set options, like -time-passes or -regalloc
from C++? I looked at the code in lib/Support/CommandLine.cpp, but the
stuff that comes closest to providing such functionality (mostly
GetOptionInfo()) is marked static.

Thanks,
Paul



From eli.friedman at gmail.com  Sun Jun  7 02:11:06 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Sun, 7 Jun 2009 02:11:06 -0700
Subject: [LLVMdev] Programmatically setting command line options?
In-Reply-To: <4A2B7EDE.9020501@assumetheposition.nl>
References: <4A2B7EDE.9020501@assumetheposition.nl>
Message-ID: <f5aa3e9b0906070211qa93fe3etdbb1c0c5438a506f@mail.gmail.com>

On Sun, Jun 7, 2009 at 1:48 AM, Paul Melis<llvm at assumetheposition.nl> wrote:
> Hello,
>
> Is there currently a way to set options, like -time-passes or -regalloc
> from C++? I looked at the code in lib/Support/CommandLine.cpp, but the
> stuff that comes closest to providing such functionality (mostly
> GetOptionInfo()) is marked static.

You can manipulate the command-line you pass to
llvm::cl::ParseCommandLineOptions; other than that, there isn't any
easy way to do it.  Patches to expose functionality using an option
into the C++ API are generally welcome if they are clean.

In an ideal world, I guess we wouldn't have any command-line options
in lib/, but adding options that way is really convenient :)

-Eli


From llvm at assumetheposition.nl  Sun Jun  7 02:41:21 2009
From: llvm at assumetheposition.nl (Paul Melis)
Date: Sun, 07 Jun 2009 11:41:21 +0200
Subject: [LLVMdev] Programmatically setting command line options?
In-Reply-To: <f5aa3e9b0906070211qa93fe3etdbb1c0c5438a506f@mail.gmail.com>
References: <4A2B7EDE.9020501@assumetheposition.nl>
	<f5aa3e9b0906070211qa93fe3etdbb1c0c5438a506f@mail.gmail.com>
Message-ID: <4A2B8B41.5020203@assumetheposition.nl>

Eli Friedman wrote:
> On Sun, Jun 7, 2009 at 1:48 AM, Paul Melis<llvm at assumetheposition.nl> wrote:
>   
>> Hello,
>>
>> Is there currently a way to set options, like -time-passes or -regalloc
>> from C++? I looked at the code in lib/Support/CommandLine.cpp, but the
>> stuff that comes closest to providing such functionality (mostly
>> GetOptionInfo()) is marked static.
>>     
>
> You can manipulate the command-line you pass to
> llvm::cl::ParseCommandLineOptions; other than that, there isn't any
> easy way to do it.  Patches to expose functionality using an option
> into the C++ API are generally welcome if they are clean.
>   
Thanks! Using ParseCommandLineOptions will do for now, I guess.
> In an ideal world, I guess we wouldn't have any command-line options
> in lib/, but adding options that way is really convenient :)
>   

Err,  yes, I can see from the sheer number of options defined there :)

Regards,
Paul


From robert at muth.org  Sun Jun  7 06:59:56 2009
From: robert at muth.org (robert muth)
Date: Sun, 7 Jun 2009 09:59:56 -0400
Subject: [LLVMdev] patch for llc/ARM: added mechanism to move switch
	tables from .text -> .data; also cleanup and documentation
In-Reply-To: <0453D1AB-FA5D-4947-BE50-02223AB8955B@apple.com>
References: <8e3491100906021826p4530f341xbb168d260c21342e@mail.gmail.com>
	<0453D1AB-FA5D-4947-BE50-02223AB8955B@apple.com>
Message-ID: <8e3491100906070659k481580afk2d562a6c4a21a2a4@mail.gmail.com>

On Sat, Jun 6, 2009 at 4:51 PM, Evan Cheng<evan.cheng at apple.com> wrote:
> +cl::opt<std::string> FlagJumpTableSection("jumptable-section",
> +                                           cl::init(".data.jtab"));
> +

I thought it would be nice to group all the jumptables together.
But as long as it stays configurable, I am fine to change the default
to ".data".

> Is this necessary? Why not just put it in the normal data section?
> Also "outline" jumptable seems like a strange term. Can you think of
> something else?


Yes, that is a tough one. How about "NonInline" instead.

Robert

> Thanks,
> Evan
>
> Sent from my iPhone
> On Jun 2, 2009, at 6:26 PM, robert muth <robert at muth.org> wrote:
>
> Hi:
>
> This is my first patch submission. Hopefully, this is the proper the
> protocol.
> Attached is a patch for the llc ARM backend:
>
> Added mechanism to generate switch table in a data section
> rather than having it interleaved with the code.
> This is controlled by command line flags and off by default.
> Also, tried to document and improve the code where I modified it.
>
> Robert
>
> <llc.patch.txt>
>
> _______________________________________________
> 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 andreaorru91 at gmail.com  Sun Jun  7 10:38:00 2009
From: andreaorru91 at gmail.com (=?ISO-8859-1?Q?Andrea_Orr=F9?=)
Date: Sun, 7 Jun 2009 19:38:00 +0200
Subject: [LLVMdev] Memory models support (-mcmodel=large)
Message-ID: <e98ccac60906071038g37e15bftde7abb395725d231@mail.gmail.com>

Hello all,

I'm developing a hobby kernel for x86-64 machines,
and I put the kernel into the higher half.

I'm trying to switch from GCC to LLVM/Clang, but it seems
that the latter doesn't support the -mcmodel=large
option, which is required in order to put the kernel
at the 0xFFFF800000000000 address in virtual memory,
as specified in my linker script:
http://pastebin.com/f2f9e0112

I've already posted in the Clang's mailing list, but it seems
that the argument is passed to LLVM, so the front-end is OK.

Any workarounds or plans for implementing that feature in LLVM?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090607/c0061f06/attachment.html>

From Sanjiv.Gupta at microchip.com  Sun Jun  7 11:13:51 2009
From: Sanjiv.Gupta at microchip.com (Sanjiv.Gupta at microchip.com)
Date: Sun, 7 Jun 2009 11:13:51 -0700
Subject: [LLVMdev] llvmc for PIC16
References: <4A2633E9.4070207@microchip.com><loom.20090604T142600-116@post.gmane.org><4A28C062.9060307@microchip.com>
	<loom.20090607T070933-452@post.gmane.org>
Message-ID: <F536B7C316F9474E9F7091239725AC9A4E90CB@CHN-CL-MAIL01.mchp-main.com>

Thanks a lot. 
This is a great help.

- Sanjiv


-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu on behalf of Mikhail Glushenkov
Sent: Sun 6/7/2009 12:49 PM
To: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] llvmc for PIC16
 
Hi Sanjiv,

Sanjiv Gupta <sanjiv.gupta <at> microchip.com> writes:

> The salient features that we want to have in the driver are:
> [...]

As promised, I've implemented a basic compiler driver for the
PIC16 toolchain. It's under tools/llvmc/examples/mcc16.

Some examples illustrating the features you requested:  

> 2. If the user has specified to generate the final executable, then 
> llvm-ld should run on all the .bc files generated by clang and create a 
> single optimized .bc file for further tools.

$ mcc16 -dry-run foo.c bar.c
clang-cc foo.c -o /tmp/llvm_6ibgr9/foo.bc 
clang-cc bar.c -o /tmp/llvm_6ibgr9/bar.bc 
llvm-ld /tmp/llvm_6ibgr9/foo.bc /tmp/llvm_6ibgr9/bar.bc \
    -o /tmp/llvm_6ibgr9/tmp.bc 
llc -f /tmp/llvm_6ibgr9/tmp.bc -o /tmp/llvm_6ibgr9/tmp.s 
native-as /tmp/llvm_6ibgr9/tmp.s -o /tmp/llvm_6ibgr9/tmp.o 
native-ld /tmp/llvm_6ibgr9/tmp.o -o a.out 

> 3. -Wo <options> - pass optimizations to the llvm-ld
> 4. mcc16 -Wl <options> - pass options to native linker.
> 5. mcc16 -Wa <options> - pass options to native assembler.

$ mcc16 -dry-run -Wo,-opt1 -Wllc,-opt2 -Wa,-opt3 -Wl,-opt4 foo.c
clang-cc foo.c -o /tmp/llvm_92HLCj/foo.bc 
llvm-ld -opt1 /tmp/llvm_92HLCj/foo.bc -o /tmp/llvm_92HLCj/tmp.bc 
llc -opt2 -f /tmp/llvm_92HLCj/tmp.bc -o /tmp/llvm_92HLCj/tmp.s 
native-as -opt3 /tmp/llvm_92HLCj/tmp.s -o /tmp/llvm_92HLCj/tmp.o 
native-ld -opt4 /tmp/llvm_92HLCj/tmp.o -o a.out 
 
> $ mcc16 -S foo.c

$ mcc16 -dry-run -S foo.c
clang-cc foo.c -o /tmp/llvm_0uiDCR/foo.bc 
llvm-ld /tmp/llvm_0uiDCR/foo.bc -o /tmp/llvm_0uiDCR/foo.bc 
llc -f /tmp/llvm_0uiDCR/foo.bc -o foo.s 

> $ mcc16 -S foo.c bar.c

$ mcc16 -dry-run -S foo.c bar.c
clang-cc foo.c -o /tmp/llvm_1zAqik/foo.bc 
llvm-ld /tmp/llvm_1zAqik/foo.bc -o /tmp/llvm_1zAqik/foo.bc 
llc -f /tmp/llvm_1zAqik/foo.bc -o foo.s 
clang-cc bar.c -o /tmp/llvm_1zAqik/bar.bc 
llvm-ld /tmp/llvm_1zAqik/bar.bc -o /tmp/llvm_1zAqik/bar.bc 
llc -f /tmp/llvm_1zAqik/bar.bc -o bar.s 

> ** Use of -g causes llvm-ld to run with -disable-opt
> $ mcc16 -S -g foo.c

$ mcc16 -dry-run -S -g foo.c   
clang-cc foo.c -o /tmp/llvm_oQFmVn/foo.bc 
llvm-ld -disable-opt /tmp/llvm_oQFmVn/foo.bc -o /tmp/llvm_oQFmVn/foo.bc 
llc -f /tmp/llvm_oQFmVn/foo.bc -o foo.s 

> ** -I is passed to clang-cc, -pre-RA-sched=list-burr to llc.
> $ mcc16 -S -g -I ../include -pre-RA-sched=list-burr foo.c

$ mcc16 -dry-run -S -g -I ../include -pre-RA-sched=list-burr foo.c
clang-cc -I ../include foo.c -o /tmp/llvm_5VxNFQ/foo.bc 
llvm-ld -disable-opt /tmp/llvm_5VxNFQ/foo.bc -o /tmp/llvm_5VxNFQ/foo.bc 
llc -pre-RA-sched list-burr -f /tmp/llvm_5VxNFQ/foo.bc -o foo.s 

This should be enough to get you started. 

I'm always happy to answer any further questions you may have. If
you want to e-mail me privately, please use the.dead.shall.rise
<at_sign> gmail dot com for now (our provider problems weren't
resolved yet).

_______________________________________________
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.llvm.org/pipermail/llvm-dev/attachments/20090607/c0dac46e/attachment.html>

From mcheva at cs.mcgill.ca  Sun Jun  7 11:27:53 2009
From: mcheva at cs.mcgill.ca (Nyx)
Date: Sun, 7 Jun 2009 11:27:53 -0700 (PDT)
Subject: [LLVMdev]  Basic Block / CFG Deep Copy?
Message-ID: <23913838.post@talk.nabble.com>


Does LLVM offer any way of obtaining a deep copy of a CFG, that is all the
basic blocks of a function and their instructions.

I'm asking because I would like to implement continuations in my VM and I
need to create a modified version of some functions. I thought a simple way
of doing this would be to modify a copy of the code generated for the
orignal function. This would be simpler than modifying all my VM logic to
generate a brand new CFG (and less time consuming).

- Maxime
-- 
View this message in context: http://www.nabble.com/Basic-Block---CFG-Deep-Copy--tp23913838p23913838.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.



From nicholas at mxc.ca  Sun Jun  7 11:46:15 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Sun, 07 Jun 2009 11:46:15 -0700
Subject: [LLVMdev] Basic Block / CFG Deep Copy?
In-Reply-To: <23913838.post@talk.nabble.com>
References: <23913838.post@talk.nabble.com>
Message-ID: <4A2C0AF7.5090406@mxc.ca>

Nyx wrote:
> Does LLVM offer any way of obtaining a deep copy of a CFG, that is all the
> basic blocks of a function and their instructions.

CloneModule and CloneFunction do what they say on the box. CloneTrace 
takes a vector<BasicBlock*> and produces a new function that includes 
just those basic blocks. This is useful for tracing based JITs.

They're declared in include/llvm/Transforms/Utils/Cloning.h.

Nick

> I'm asking because I would like to implement continuations in my VM and I
> need to create a modified version of some functions. I thought a simple way
> of doing this would be to modify a copy of the code generated for the
> orignal function. This would be simpler than modifying all my VM logic to
> generate a brand new CFG (and less time consuming).
> 
> - Maxime



From evan.cheng at apple.com  Sun Jun  7 20:53:23 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Sun, 7 Jun 2009 20:53:23 -0700
Subject: [LLVMdev] patch for llc/ARM: added mechanism to move
	switch	tables from .text -> .data; also cleanup and documentation
In-Reply-To: <8e3491100906070659k481580afk2d562a6c4a21a2a4@mail.gmail.com>
References: <8e3491100906021826p4530f341xbb168d260c21342e@mail.gmail.com>
	<0453D1AB-FA5D-4947-BE50-02223AB8955B@apple.com>
	<8e3491100906070659k481580afk2d562a6c4a21a2a4@mail.gmail.com>
Message-ID: <C2EC9000-8447-42CB-B3CD-5DB1652C356F@apple.com>


On Jun 7, 2009, at 6:59 AM, robert muth wrote:

> On Sat, Jun 6, 2009 at 4:51 PM, Evan Cheng<evan.cheng at apple.com>  
> wrote:
>> +cl::opt<std::string> FlagJumpTableSection("jumptable-section",
>> +                                           cl::init(".data.jtab"));
>> +
>
> I thought it would be nice to group all the jumptables together.
> But as long as it stays configurable, I am fine to change the default
> to ".data".

There is already a TargetAsmInfo::JumpTableDataSection. Why not just  
use that?

>
>> Is this necessary? Why not just put it in the normal data section?
>> Also "outline" jumptable seems like a strange term. Can you think of
>> something else?
>
>
> Yes, that is a tough one. How about "NonInline" instead.

Or "OutOfLine"?

Please add a test case as well. Thanks,

Evan

>
> Robert
>
>> Thanks,
>> Evan
>>
>> Sent from my iPhone
>> On Jun 2, 2009, at 6:26 PM, robert muth <robert at muth.org> wrote:
>>
>> Hi:
>>
>> This is my first patch submission. Hopefully, this is the proper the
>> protocol.
>> Attached is a patch for the llc ARM backend:
>>
>> Added mechanism to generate switch table in a data section
>> rather than having it interleaved with the code.
>> This is controlled by command line flags and off by default.
>> Also, tried to document and improve the code where I modified it.
>>
>> Robert
>>
>> <llc.patch.txt>
>>
>> _______________________________________________
>> 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
>>
>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



From HCain at nds.com  Mon Jun  8 00:13:18 2009
From: HCain at nds.com (Cain, Harel)
Date: Mon, 8 Jun 2009 09:13:18 +0200
Subject: [LLVMdev] Replacing unconditional branches with conditional ones
Message-ID: <6EFD3F7A08B04846BEC3A627D786495645698BAD22@ILMA1.IL.NDS.COM>

Hi all,

Somewhat of a newbie's question, hope you can help me out.

I'm trying to turn unconditional BranchInst's into conditional ones (with a condition I'm supplying) branching between the original target and a basic block of my choice.
Apparently the way to do that is to create a new conditional BranchInst and remove the unconditional one from its basic block. However when removing the unconditional branch, its target's predecessor list seems not to be updated, so that the end result is for the original target to have duplicates in its predecessor list, sometimes even an a "null" predecessor for some reason.
Can you advise what's the safest, recommended way to replace an unconditional branch with a conditional one?



Thanks,

Harel

________________________________
This e-mail is confidential, the property of NDS Ltd and intended for the addressee only. Any dissemination, copying or distribution of this message or any attachments by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please immediately notify the postmaster at nds.com and destroy the original message. Messages sent to and from NDS may be monitored. NDS cannot guarantee any message delivery method is secure or error-free. Information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. We do not accept responsibility for any errors or omissions in this message and/or attachment that arise as a result of transmission. You should carry out your own virus checks before opening any attachment. Any views or opinions presented are solely those of the author and do not necessarily represent those of NDS.

To protect the environment please do not print this e-mail unless necessary.

NDS Limited Registered Office: One London Road, Staines,Middlesex TW18 4EX, United Kingdom. A company registered in England and Wales Registered no. 3080780 VAT no. GB 603 8808 40-00
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090608/6aa6494a/attachment.html>

From npjohnso at cs.princeton.edu  Mon Jun  8 01:12:35 2009
From: npjohnso at cs.princeton.edu (Nick Johnson)
Date: Mon, 8 Jun 2009 13:42:35 +0530
Subject: [LLVMdev] Replacing unconditional branches with conditional ones
In-Reply-To: <6EFD3F7A08B04846BEC3A627D786495645698BAD22@ILMA1.IL.NDS.COM>
References: <6EFD3F7A08B04846BEC3A627D786495645698BAD22@ILMA1.IL.NDS.COM>
Message-ID: <d85094510906080112y52dcfe8fm78a8f28d41d3a034@mail.gmail.com>

Harel,

You should also call .eraseFromParent() on the old branch instruction.

Nick


On Mon, Jun 8, 2009 at 12:43 PM, Cain, Harel<HCain at nds.com> wrote:
> Hi all,
>
> Somewhat of a newbie's question, hope you can help me out.
>
> I'm trying to turn unconditional BranchInst's into conditional ones (with a
> condition I'm supplying) branching between the original target and a basic
> block of my choice.
> Apparently the way to do that is to create a new conditional BranchInst and
> remove the unconditional one from its basic block. However when removing the
> unconditional branch, its target's predecessor list seems not to be updated,
> so that the end result is for the original target to have duplicates in its
> predecessor list, sometimes even an a "null" predecessor for some reason.
> Can you advise what's the safest, recommended way to replace an
> unconditional branch with a conditional one?
>
>
>
> Thanks,
>
> Harel
> ________________________________
> This e-mail is confidential, the property of NDS Ltd and intended for the
> addressee only. Any dissemination, copying or distribution of this message
> or any attachments by anyone other than the intended recipient is strictly
> prohibited. If you have received this message in error, please immediately
> notify the postmaster at nds.com and destroy the original message. Messages
> sent to and from NDS may be monitored. NDS cannot guarantee any message
> delivery method is secure or error-free. Information could be intercepted,
> corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.
> We do not accept responsibility for any errors or omissions in this message
> and/or attachment that arise as a result of transmission. You should carry
> out your own virus checks before opening any attachment. Any views or
> opinions presented are solely those of the author and do not necessarily
> represent those of NDS.
>
> To protect the environment please do not print this e-mail unless necessary.
>
> NDS Limited Registered Office: One London Road, Staines,Middlesex TW18 4EX,
> United Kingdom. A company registered in England and Wales Registered no.
> 3080780 VAT no. GB 603 8808 40-00
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>



-- 
Nick Johnson



From Christian.Sayer at dibcom.fr  Mon Jun  8 01:23:57 2009
From: Christian.Sayer at dibcom.fr (Christian Sayer)
Date: Mon, 8 Jun 2009 10:23:57 +0200
Subject: [LLVMdev] Tablegen question
In-Reply-To: <68c4c3e20906060947h7cc89277uf41a0d8c9ffabe89@mail.gmail.com>
References: <68c4c3e20906060947h7cc89277uf41a0d8c9ffabe89@mail.gmail.com>
Message-ID: <57C38DA176A0A34A9B9F3CCCE33D3C4AFB244D2ECB@FRPAR1CL009.coe.adi.dibcom.com>

Manjunath,
I asked this question recently, but instead of telling you to search the archive
I'm going to take it as a chance to recall how to do it (because I'll do so anyway
and even telling tablegen to use an enum for instructions is not as trivial to do
as you might think : )

I wrote it up in the wiki at
http://wiki.llvm.org/HowTo:_Add_arbitrary_properties_to_instructions


Regards,
Christian

--
  Christian SAYER


> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu
> [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Manjunath Kudlur
> Sent: Saturday, June 06, 2009 6:47 PM
> To: LLVM Developers Mailing List
> Subject: [LLVMdev] Tablegen question
>
> I want to add a set of "properties" to each instruction in my
> instruction set, and want to be able to query that in my
> machine-specific optimizations. My Insts.td file looks as follows :
>
> class InstProperty;
>
> def propX : InstProperty;
> def propY : InstProperty;
> def propZ : InstProperty;
>
> class myInst<..., list<InstProperty> props> : Instruction {
>   ...
>   ...
>   list<InstProperty> Properties=props;
> }
>
> def i1 : myInst<..., [propX]>;
> def i2 : myInst<..., [propX, propZ]>;
> def i3 : myInst<..., []>;
>
> I want to add a Tablegen backend that would look for Instructions
> derived from myInst, look for Properties field, and output a
> opcode->bitfield map as follows:
>
> PropMap[myInst::i1] = propX;
> PropMap[myInst::i2] = propX | propZ;
> PropMap[myInst::i3] = 0;
>
> where propX,propY,and propZ will be defined as appropriate enums.
> Now, I looked at the current Tablegen backends, and I didn't find any
> that are specific to a particular architecture backend, say, to X86 or
> Sparc etc.. That got me wondering if I am breaking some conventions
> and not doing things in the LLVM-way. Is what I am trying to do an
> intended use case for Tablegen? Why aren't there Tablegen backends
> specific to some architecture backends? I would be grateful for any
> advice from the community.
>
> Manjunath
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>




--

CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of the person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify the sender. Please also permanently delete all copies of the original message and any attached documentation. Thank you.



From Vasudev.Negi at microchip.com  Mon Jun  8 03:25:27 2009
From: Vasudev.Negi at microchip.com (Vasudev.Negi at microchip.com)
Date: Mon, 8 Jun 2009 03:25:27 -0700
Subject: [LLVMdev] debug information for functions
Message-ID: <F536B7C316F9474E9F7091239725AC9A02977F0D@CHN-CL-MAIL01.mchp-main.com>

Suppose I have fun.h as:

 

static  void fun() {

  int a =10;

}

 

Now I have two files foo.c and goo.c as 

foo.c :

#include "fun.h"

void foo() 

{

  fun();

}

 

goo.c:

#include "fun.h"

void goo()

{

  fun();

}

 

I get .bc files for foo.c and foo.bc through clang. Now I run llvm-ld
with -disable-opt for foo.bc and goo.bc. In the resulting .bc files, one
of the two functions fun, is renamed to fun<number>. There are two
llvm.dbg.subprogram descriptors created for the two fun functions. Both
have name foo . So there is no way to know which descriptor represents
which function. I am trying to get this information in assembly printer.

 


Proposed solution :  llvm.dbg.subprogram.type should have a reference to
function is represents. This is in the same way as
llvm.dbg.global_variable.type has a reference to global variable it
represents.

 

Thanks

Vasudev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 5980 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090608/ac253293/attachment.bin>

From marcus at propellerheads.se  Mon Jun  8 03:30:05 2009
From: marcus at propellerheads.se (Marcus Zetterquist)
Date: Mon, 8 Jun 2009 12:30:05 +0200
Subject: [LLVMdev] I apologize for the duplicate messages [nt]
Message-ID: <14ABC355-281A-4650-9235-D9ACDB89079A@propellerheads.se>




From bobby at sharedrealm.com  Mon Jun  8 06:34:02 2009
From: bobby at sharedrealm.com (Robert G. Jakabosky)
Date: Mon, 8 Jun 2009 06:34:02 -0700
Subject: [LLVMdev] How to stop symbol searching without aborting
In-Reply-To: <421B2CED-8DC3-419E-8ACF-CB6643164214@gmail.com>
References: <421B2CED-8DC3-419E-8ACF-CB6643164214@gmail.com>
Message-ID: <200906080634.02949.bobby@sharedrealm.com>


Have you tried llvm-lua?  It adds JIT & static compiling support to the Lua VM 
using LLVM as the backend.  I just released version 1.0 about a week ago.

The project website is here:
http://code.google.com/p/llvm-lua/

On Friday 05, Marcus Zetterquist wrote:
> Hi!
>
>
> Today we use Lua to let 3rd party developers add driver-like modules
> to our application.
>
> The advantages to using Lua compared to DLL:s etc. are that:
>
> 1) the same driver binary can be used on all OS:es and processor
> architectures etc.
>
> 2) We can provide a small API to the Lua drivers and they _cannot_
> call any other external functions.
>
> 3) A buggy driver cannot crash our application. (Almost true statement.)
>
>
> I'm looking into using LLVM and the bitcode format for this instead.
> The additional, very important advantages are:
>
> 4) 3rd parties can port existing (huge amounts of) C / C++ code much
> easier - no need to rewrite all code in Lua.
>
> 5) Performance. We will use the LLVM JIT.
>
>
> Problem: I can't figure out how to do (2) with the LLVM JIT.
>
> It is very important that the driver does not have access to any other
> function in the application except those I provide. It's not OK for
> our application to abort if a driver calls an undefined function - I
> want to just disable _that driver_ in that event.
>
> I can use DisableSymbolSearching() but that causes application to
> abort for unknown symbols.
>
>
> Please advice!
>
>
> /Marcus
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



-- 
Robert G. Jakabosky


From criswell at cs.uiuc.edu  Mon Jun  8 07:34:05 2009
From: criswell at cs.uiuc.edu (John Criswell)
Date: Mon, 8 Jun 2009 09:34:05 -0500
Subject: [LLVMdev] Analysis Pass
In-Reply-To: <4f5edbea0906050950s495e9019pa4e93d54f7ef6df9@mail.gmail.com>
References: <4f5edbea0906050950s495e9019pa4e93d54f7ef6df9@mail.gmail.com>
Message-ID: <4A2D215D.8070307@cs.uiuc.edu>

Rotem Varon wrote:
> Hi,
>
> I am trying to set a prerequisite pass.
>
>
> void PassName::getAnalysisUsage(AnalysisUsage &AU) const
>     {
>         AU.setPreservesAll();
>         AU.addRequired<LiveVariables>();
>     }
>
> But when i am running the pass with the opt i get this error:
> undefined symbol: _ZN4llvm13LiveVariables2IDE
>   
I'm not sure if this has already been answered, so I'll answer it.
:)

The reason why you're getting this error is because the code containing
the LiveVariables pass is not compiled into the opt program and it is
not loaded into the opt program via the -load option.  The reason for
that, I suspect, is that LiveVariables, I believe, is a pass that is
used for code generation (i.e., it is not a pure LLVM IR
transformation), so it is not included in opt.

-- John T.

> If you need more information ...
>
> Thank you.
>   



From pejic at ualberta.ca  Mon Jun  8 08:26:48 2009
From: pejic at ualberta.ca (Slobodan Pejic)
Date: Mon, 08 Jun 2009 09:26:48 -0600
Subject: [LLVMdev] Linking runtime for edge profiling.
Message-ID: <4A2D2DB8.7040001@ualberta.ca>

Hi,

The profiling library (lib/libprofile_rt.bca built with gmake from 
runtime/libprofile) generates an archive with a profile_rt.o file that 
is actually a shell script, a wrapper around lli.  I found the error in 
Makefile.rules, but I do know where else this needs to change (CMake and 
such.)  The change to Makefile.rules is attached.

Thanks,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RulesLinkAsLibrary.diff
Type: text/x-patch
Size: 370 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090608/5d5636d0/attachment.bin>

From vgrover528 at gmail.com  Mon Jun  8 09:27:50 2009
From: vgrover528 at gmail.com (Vinod Grover)
Date: Mon, 8 Jun 2009 09:27:50 -0700
Subject: [LLVMdev] Structured Exception Handling (SEH) on Windows
In-Reply-To: <D848267A-DF3E-4A3F-9283-1C1C4262E909@alacatialabs.com>
References: <F963D117-1443-48F6-BB1D-5F74808C674A@alacatialabs.com>
	<f5aa3e9b0906031550l661b6ba4l44c45af09e1a7994@mail.gmail.com>
	<D848267A-DF3E-4A3F-9283-1C1C4262E909@alacatialabs.com>
Message-ID: <35657f570906080927p32b50b18tee48f1158382a5fa@mail.gmail.com>

SEH is not a superset of C++ exception handling - it is Windows exception
handling

On Wed, Jun ion 3, 2009 at 8:57 PM, Joe Ranieri <joe at alacatialabs.com>wrote:

>
> On Jun 3, 2009, at 18:50, Eli Friedman wrote:
>
> > On Wed, Jun 3, 2009 at 2:20 PM, Joe Ranieri<joe at alacatialabs.com>
> > wrote:
> >> Has any progress been made on structured exception handling on
> >> Windows? I saw a post by Duncan Sands back in September 2008, but
> >> haven't seen anything since. I'm trying to generate code to run on
> >> Windows, but would really prefer not to ship libgcc...
> >
> > I fail to see the connection between SEH support and libgcc; for C++
> > exceptions to work, you will need libgcc anyway.
>
> Well, I had thought that SEH was a superset of C++ exception handling,
> similar to how the unwind library is to the C++ exception handling
> with libgcc. Looking further into this, it seems not to be the case.
> What I'd like to end up with is exceptions compatible with DLLs
> generated with Visual Studio C++. I'm not much of a Windows person, so
> don't really know the best way to approach it.
>
> However, this is a long term goal, and for now I just need an
> exception system to work inside of the code I generate with LLVM.
> Since I don't really have much time to spend on this, I think for now
> I'll implement something quick and dirty using setjmp/longjmp.
>
> Anyone have better ideas?
>
> -- Joe Ranieri
> _______________________________________________
> 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.llvm.org/pipermail/llvm-dev/attachments/20090608/818bd305/attachment.html>

From keveman at gmail.com  Mon Jun  8 09:58:58 2009
From: keveman at gmail.com (Manjunath Kudlur)
Date: Mon, 8 Jun 2009 09:58:58 -0700
Subject: [LLVMdev] Tablegen question
In-Reply-To: <57C38DA176A0A34A9B9F3CCCE33D3C4AFB244D2ECB@FRPAR1CL009.coe.adi.dibcom.com>
References: <68c4c3e20906060947h7cc89277uf41a0d8c9ffabe89@mail.gmail.com>
	<57C38DA176A0A34A9B9F3CCCE33D3C4AFB244D2ECB@FRPAR1CL009.coe.adi.dibcom.com>
Message-ID: <68c4c3e20906080958y6ed1ad9ay1d9f5ddd4adcfdf2@mail.gmail.com>

Christian,

Thanks for your reply and the wiki entry. I did search the archives,
but evidently I didn't search for the right thing. My bad. Anyways, I
am still wondering about the other part of my question. Why aren't
there Tablegen backends specific to some architecture backends? Let me
describe a different scenario. Suppose my architecture has vector and
scalar units, and suppose I want to write a machine function pass that
takes some work from the vector units and gives it to the scalar
units, for load balancing purposes. In that pass, I need to convert
some vector instructions in to a sequence of scalar instructions. For
this, I need to know what scalar instruction to generate for a vector
instruction. For example, myInst::AddV4 should become 4 myInst::Add,
etc. I need this opcode->opcode map, that can provide me this
information for all vector instructions. One way I can think of is,
put this information along with the vector instruction description in
the .td file.

class vecInst<...,myInst s> :  myInst<...> {
  myInst scalarVersion=s;
}

def AddV4 : vecInst<..., Add>;
def SubV2 : vecInst<..., Sub>;
...
def ORV4 : vecInst<..., OR>;

Now, I can write a tablegen backend that can output a opcode->opcode
map, which can be used by the pass. Is this and intended use case for
Tablegen? Or, are tablegen backends supposed to be generic to all
architecture backends?

Manjunath

On Mon, Jun 8, 2009 at 1:23 AM, Christian
Sayer<Christian.Sayer at dibcom.fr> wrote:
> Manjunath,
> I asked this question recently, but instead of telling you to search the archive
> I'm going to take it as a chance to recall how to do it (because I'll do so anyway
> and even telling tablegen to use an enum for instructions is not as trivial to do
> as you might think : )
>
> I wrote it up in the wiki at
> http://wiki.llvm.org/HowTo:_Add_arbitrary_properties_to_instructions
>
>
> Regards,
> Christian
>
> --
>  Christian SAYER
>
>
>> -----Original Message-----
>> From: llvmdev-bounces at cs.uiuc.edu
>> [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Manjunath Kudlur
>> Sent: Saturday, June 06, 2009 6:47 PM
>> To: LLVM Developers Mailing List
>> Subject: [LLVMdev] Tablegen question
>>
>> I want to add a set of "properties" to each instruction in my
>> instruction set, and want to be able to query that in my
>> machine-specific optimizations. My Insts.td file looks as follows :
>>
>> class InstProperty;
>>
>> def propX : InstProperty;
>> def propY : InstProperty;
>> def propZ : InstProperty;
>>
>> class myInst<..., list<InstProperty> props> : Instruction {
>>   ...
>>   ...
>>   list<InstProperty> Properties=props;
>> }
>>
>> def i1 : myInst<..., [propX]>;
>> def i2 : myInst<..., [propX, propZ]>;
>> def i3 : myInst<..., []>;
>>
>> I want to add a Tablegen backend that would look for Instructions
>> derived from myInst, look for Properties field, and output a
>> opcode->bitfield map as follows:
>>
>> PropMap[myInst::i1] = propX;
>> PropMap[myInst::i2] = propX | propZ;
>> PropMap[myInst::i3] = 0;
>>
>> where propX,propY,and propZ will be defined as appropriate enums.
>> Now, I looked at the current Tablegen backends, and I didn't find any
>> that are specific to a particular architecture backend, say, to X86 or
>> Sparc etc.. That got me wondering if I am breaking some conventions
>> and not doing things in the LLVM-way. Is what I am trying to do an
>> intended use case for Tablegen? Why aren't there Tablegen backends
>> specific to some architecture backends? I would be grateful for any
>> advice from the community.
>>
>> Manjunath
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
>
>
>
> --
>
> CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of the person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify the sender. Please also permanently delete all copies of the original message and any attached documentation. Thank you.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>



From Alireza.Moshtaghi at microchip.com  Mon Jun  8 10:02:33 2009
From: Alireza.Moshtaghi at microchip.com (Alireza.Moshtaghi at microchip.com)
Date: Mon, 8 Jun 2009 10:02:33 -0700
Subject: [LLVMdev] debug information for functions
In-Reply-To: <F536B7C316F9474E9F7091239725AC9A02977F0D@CHN-CL-MAIL01.mchp-main.com>
References: <F536B7C316F9474E9F7091239725AC9A02977F0D@CHN-CL-MAIL01.mchp-main.com>
Message-ID: <C9F1221126AF8A4BBCFFA4FA3AFA5290029E7966@CHN-CL-MAIL01.mchp-main.com>

I would assume this is similar to the problem of dealing with structure
tags, and I guess your proposal is along lines of the same solution
right? 

 

A.

 

________________________________

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
On Behalf Of Vasudev.Negi at microchip.com
Sent: Monday, June 08, 2009 3:25 AM
To: llvmdev at cs.uiuc.edu
Subject: debug information for functions

 

Suppose I have fun.h as:

 

static  void fun() {

  int a =10;

}

 

Now I have two files foo.c and goo.c as 

foo.c :

#include "fun.h"

void foo() 

{

  fun();

}

 

goo.c:

#include "fun.h"

void goo()

{

  fun();

}

 

I get .bc files for foo.c and foo.bc through clang. Now I run llvm-ld
with -disable-opt for foo.bc and goo.bc. In the resulting .bc files, one
of the two functions fun, is renamed to fun<number>. There are two
llvm.dbg.subprogram descriptors created for the two fun functions. Both
have name foo . So there is no way to know which descriptor represents
which function. I am trying to get this information in assembly printer.

 


Proposed solution :  llvm.dbg.subprogram.type should have a reference to
function is represents. This is in the same way as
llvm.dbg.global_variable.type has a reference to global variable it
represents.

 

Thanks

Vasudev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090608/4a413879/attachment.html>

From devang.patel at gmail.com  Mon Jun  8 10:19:19 2009
From: devang.patel at gmail.com (Devang Patel)
Date: Mon, 8 Jun 2009 10:19:19 -0700
Subject: [LLVMdev] addRequired(), Loop Unrolling
In-Reply-To: <4f5edbea0906060838v3689dadbs5abf0766533c983a@mail.gmail.com>
References: <4f5edbea0906060838v3689dadbs5abf0766533c983a@mail.gmail.com>
Message-ID: <352a1fb20906081019w6de5fdabyfa19166628448d74@mail.gmail.com>

On Sat, Jun 6, 2009 at 8:38 AM, Rotem Varon<varonrotem at gmail.com> wrote:
> Hi,
>
> I am trying to set loop unrolling as a required pass.
> AU.addRequired<LoopUnroll>();

In general, it is  good idea to schedule loop unrolling pass (using
PassManager.add()) at the appropriate place in your optimization
queue. AnalysisUsage.addRequired() is best suited for analysis not
transformations.

> should I include any header file?
> How can I be possessive that "LoopUnroll" is the name I need ?

?
-
Devang


From devang.patel at gmail.com  Mon Jun  8 10:32:48 2009
From: devang.patel at gmail.com (Devang Patel)
Date: Mon, 8 Jun 2009 10:32:48 -0700
Subject: [LLVMdev] debug information for functions
In-Reply-To: <F536B7C316F9474E9F7091239725AC9A02977F0D@CHN-CL-MAIL01.mchp-main.com>
References: <F536B7C316F9474E9F7091239725AC9A02977F0D@CHN-CL-MAIL01.mchp-main.com>
Message-ID: <352a1fb20906081032y503ebb77icc9b4e7212906d54@mail.gmail.com>

On Mon, Jun 8, 2009 at 3:25 AM, <Vasudev.Negi at microchip.com> wrote:
>
> I get .bc files for foo.c and foo.bc through clang. Now I run llvm-ld
> with -disable-opt for foo.bc and goo.bc. In the resulting .bc files, one
> of the two functions fun, is renamed to fun<number>. There are two
> llvm.dbg.subprogram descriptors created for the two fun functions. Both
> have name foo . So there is no way to know which descriptor represents
> which function. I am trying to get this information in assembly printer.

What is the use of this info ? The descriptor includes enough location
info (thru func.start) and the display name for static functions.

-
Devang


From devang.patel at gmail.com  Mon Jun  8 10:38:28 2009
From: devang.patel at gmail.com (Devang Patel)
Date: Mon, 8 Jun 2009 10:38:28 -0700
Subject: [LLVMdev] Can llvm-2.5 work with "-O1 -g"?
In-Reply-To: <20090606115612.v5tk8rpy1hc088w8@cubmail.cc.columbia.edu>
References: <4f5edbea0906060838v3689dadbs5abf0766533c983a@mail.gmail.com>
	<20090606115612.v5tk8rpy1hc088w8@cubmail.cc.columbia.edu>
Message-ID: <352a1fb20906081038i3cdf19e5x51a0444472906557@mail.gmail.com>

On Sat, Jun 6, 2009 at 8:56 AM, <hc2428 at columbia.edu> wrote:
> Dear staff,
>
>     I need to get the line number and file name information of the
> source code for each instruction in *.bc file. I find that llvm-2.4
> can not support "-O1 -g", which means if we are at O1 to O3
> optimization level, we can not get any dbg.stoppoint inserted into the
> LLVM IR.
>
>     However, our project requires us to get the line number and file
> name information of the source code for each instruction in *.bc file
> at any Ox level. I have built and run llvm-2.5 and found that it still
> can not support "-Ox -g".
>
>     If we are not using "-g", do we have other ways to get the line
> number and file name information for each instruction in *.bc file?


llvm-gcc and llvm sources in mainline svn repository supports location
information at various optimization levels (it is not supported at -O4
level at the moment)

-
Devang



From criswell at cs.uiuc.edu  Mon Jun  8 10:49:30 2009
From: criswell at cs.uiuc.edu (John Criswell)
Date: Mon, 8 Jun 2009 12:49:30 -0500
Subject: [LLVMdev] Web Server Restart
Message-ID: <4A2D4F2A.4060508@cs.uiuc.edu>

Dear All,

I will be restarting the web server at 4:00 pm Central Daylight time to
add a new virtual host to the server's configuration
(dpj.cs.illinois.edu for those that are curious).  I will email the list
when the restart is complete.

Please refrain from SVN commits starting at 4:00 pm CDT.

Thanks.

-- John T.



From gohman at apple.com  Mon Jun  8 11:26:00 2009
From: gohman at apple.com (Dan Gohman)
Date: Mon, 8 Jun 2009 11:26:00 -0700
Subject: [LLVMdev] LiveValues Pass
In-Reply-To: <4f5edbea0906060112p351659a1l6538c057eb44223f@mail.gmail.com>
References: <4f5edbea0906020554h6f8d6fbfp3ea5d2e74b8077@mail.gmail.com>
	<87892836-C3D5-4044-9D28-0561A3F54F20@apple.com>
	<4f5edbea0906060112p351659a1l6538c057eb44223f@mail.gmail.com>
Message-ID: <00A6211D-AC1F-40D7-BD59-6181D49F5ABA@apple.com>

You are apparently mixing source between different versions of LLVM.

Dan

On Jun 6, 2009, at 1:12 AM, Rotem Varon wrote:


> Hi,
>
> I tried to use the LiveValues pass without success.
> I did exactly as you wrote me but no luck for me.
> I am getting this error :
>
> [rotem at localhost ~]$ opt -load /home/rotem/Desktop/install/Release/ 
> lib/BBPass.so -BBPass < /home/rotem/Desktop/tmp/BBtry.bc > /dev/null
> Error opening '/home/rotem/Desktop/install/Release/lib/BBPass.so': / 
> home/rotem/Desktop/install/Release/lib/BBPass.so: undefined symbol:  
> _ZN4llvm10LiveValues2IDE
>   -load request ignored.
> opt: Unknown command line argument '-BBPass'.  Try: 'opt --help'
>
> I tried also to relocate the LiveValues to the same directory of me  
> pass. This is the error:
>
> llvm[0]: Compiling BBPass.cpp for Release build  (PIC)
> llvm[0]: Compiling LiveValues.cpp for Release build  (PIC)
> LiveValues.cpp: In member function 'llvm::LiveValues::Memo&  
> llvm::LiveValues::compute(const llvm::Value*)':
> LiveValues.cpp:150: error: 'const class llvm::PHINode' has no member  
> named 'getIncomingValueNumForOperand'
>
> I really need your help here
> Thank you.
>



From gohman at apple.com  Mon Jun  8 12:07:41 2009
From: gohman at apple.com (Dan Gohman)
Date: Mon, 8 Jun 2009 12:07:41 -0700
Subject: [LLVMdev] Memory models support (-mcmodel=large)
In-Reply-To: <e98ccac60906071038g37e15bftde7abb395725d231@mail.gmail.com>
References: <e98ccac60906071038g37e15bftde7abb395725d231@mail.gmail.com>
Message-ID: <B7C78094-6B4A-4AD0-840A-4977338705FB@apple.com>


On Jun 7, 2009, at 10:38 AM, Andrea Orrù wrote:


> Hello all,
>
> I'm developing a hobby kernel for x86-64 machines,
> and I put the kernel into the higher half.
>
> I'm trying to switch from GCC to LLVM/Clang, but it seems
> that the latter doesn't support the -mcmodel=large
> option, which is required in order to put the kernel
> at the 0xFFFF800000000000 address in virtual memory,
> as specified in my linker script:
> http://pastebin.com/f2f9e0112
>
> I've already posted in the Clang's mailing list, but it seems
> that the argument is passed to LLVM, so the front-end is OK.
>
> Any workarounds or plans for implementing that feature in LLVM?

There's some code in place, but it's not complete. It's waiting
for someone who needs the feature to step forward and finish it.

Dan




From gohman at apple.com  Mon Jun  8 12:07:50 2009
From: gohman at apple.com (Dan Gohman)
Date: Mon, 8 Jun 2009 12:07:50 -0700
Subject: [LLVMdev] Tablegen question
In-Reply-To: <68c4c3e20906080958y6ed1ad9ay1d9f5ddd4adcfdf2@mail.gmail.com>
References: <68c4c3e20906060947h7cc89277uf41a0d8c9ffabe89@mail.gmail.com>
	<57C38DA176A0A34A9B9F3CCCE33D3C4AFB244D2ECB@FRPAR1CL009.coe.adi.dibcom.com>
	<68c4c3e20906080958y6ed1ad9ay1d9f5ddd4adcfdf2@mail.gmail.com>
Message-ID: <B96B557C-F46A-49CD-A6DA-7D3092E74E4F@apple.com>


On Jun 8, 2009, at 9:58 AM, Manjunath Kudlur wrote:
>
> Now, I can write a tablegen backend that can output a opcode->opcode
> map, which can be used by the pass. Is this and intended use case for
> Tablegen? Or, are tablegen backends supposed to be generic to all
> architecture backends?

In general, it's a design goal to structure CodeGen features as
target-independent code parameterized with target-specific data.
The degree to which this goal is met in LLVM CodeGen features today
varies, but features that have been implemented using TableGen have
been relatively successful.

Dan



From keveman at gmail.com  Mon Jun  8 13:25:22 2009
From: keveman at gmail.com (Manjunath Kudlur)
Date: Mon, 8 Jun 2009 13:25:22 -0700
Subject: [LLVMdev] Tablegen question
In-Reply-To: <B96B557C-F46A-49CD-A6DA-7D3092E74E4F@apple.com>
References: <68c4c3e20906060947h7cc89277uf41a0d8c9ffabe89@mail.gmail.com>
	<57C38DA176A0A34A9B9F3CCCE33D3C4AFB244D2ECB@FRPAR1CL009.coe.adi.dibcom.com>
	<68c4c3e20906080958y6ed1ad9ay1d9f5ddd4adcfdf2@mail.gmail.com>
	<B96B557C-F46A-49CD-A6DA-7D3092E74E4F@apple.com>
Message-ID: <68c4c3e20906081325r193ade4co57841c1f3ed08842@mail.gmail.com>

Dan,

> In general, it's a design goal to structure CodeGen features as
> target-independent code parameterized with target-specific data.
> The degree to which this goal is met in LLVM CodeGen features today
> varies, but features that have been implemented using TableGen have
> been relatively successful.

Can you give an example of a relatively successful instance where
Tablegen was used to implement something specific for a target?

Manjunath


From manoel at fonetica.com.br  Mon Jun  8 13:53:20 2009
From: manoel at fonetica.com.br (=?ISO-8859-1?Q?Manoel=20Teixeira?=)
Date: Mon,  8 Jun 2009 17:53:20 -0300
Subject: [LLVMdev] Structure alignment
In-Reply-To: <mailman.3.1244480402.31578.llvmdev@cs.uiuc.edu>
References: <mailman.3.1244480402.31578.llvmdev@cs.uiuc.edu>
Message-ID: <20090608205320.6174.qmail@hm885.locaweb.com.br>


%FIRSTSTRU = type { i32,  double, i32, i8* }

struct  {
	int				var1;
	double			var2;
	int				var3;
	char	*var4;
}firstStru ;

Could someone help? 
If, running a application in windows with MSVC,  I allocate a memmory buffer and call a LLVM 
function with such buffer, there's a structure alignment problem.
If the LLVM function call a C function using the same buffer, it runs fine.
Any ideas?

Thanks,


Manoel Teixeira






 


From criswell at cs.uiuc.edu  Mon Jun  8 14:02:00 2009
From: criswell at cs.uiuc.edu (John Criswell)
Date: Mon, 8 Jun 2009 16:02:00 -0500
Subject: [LLVMdev] LLVM Services Back Online
Message-ID: <4A2D7C48.3060600@cs.uiuc.edu>

Dear All,

The web server restart was a success, and all LLVM services should be
back online.

If you run into any problems, please let me know.

Thanks.

-- John T.



From eli.friedman at gmail.com  Mon Jun  8 14:15:26 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Mon, 8 Jun 2009 14:15:26 -0700
Subject: [LLVMdev] Structure alignment
In-Reply-To: <20090608205320.6174.qmail@hm885.locaweb.com.br>
References: <mailman.3.1244480402.31578.llvmdev@cs.uiuc.edu>
	<20090608205320.6174.qmail@hm885.locaweb.com.br>
Message-ID: <f5aa3e9b0906081415oa706eadh21a7814c0f95e006@mail.gmail.com>

On Mon, Jun 8, 2009 at 1:53 PM, Manoel Teixeira<manoel at fonetica.com.br> wrote:
>
> %FIRSTSTRU = type { i32,  double, i32, i8* }
>
> struct  {
>        int                             var1;
>        double                  var2;
>        int                             var3;
>        char    *var4;
> }firstStru ;
>
> Could someone help?
> If, running a application in windows with MSVC,  I allocate a memmory buffer and call a LLVM
> function with such buffer, there's a structure alignment problem.
> If the LLVM function call a C function using the same buffer, it runs fine.
> Any ideas?

You're probably passing in the wrong string to the TargetData; try
something like the following:
target datalayout =
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"

-Eli



From simmon12 at cs.uiuc.edu  Mon Jun  8 14:27:37 2009
From: simmon12 at cs.uiuc.edu (Patrick Alexander Simmons)
Date: Mon, 08 Jun 2009 15:27:37 -0600
Subject: [LLVMdev] Pool Allocation and DSA
Message-ID: <4A2D8249.3090604@cs.uiuc.edu>

I don't really have a specific question, but, as I've been looking 
through pool allocation and the DS graphs extensively, I wanted to 
verify that my understanding of the representations used is correct.  
Therefore, I'm summarizing my understanding below (which, if it's 
correct, may hopefully be helpful to others).  I would appreciate if 
someone who understands pool allocation well would comment on whether 
I'm right in my understanding.

After pool allocation runs, each Function is associated with a DS 
graph.  Each node in a Function's DS graph falls into one of the 
following categories:

1.  The node corresponds to a global pool.
2.  The node corresponds to a pool created by the Function.
3.  The node corresponds to a formal parameter passed to the function 
(and is the result of conservatively folding all possible actual 
parameters that may be passed to the function).
4.  The node corresponds to a pool parameter passed to the Function.
5.  The node is not in categories 1-4, in which case it must be pointed 
to by some other pool which either is in categories 1-4 or is pointed to 
by some other node, for which the same condition must hold.  That is to 
say, all nodes in the graph must be reachable by following the edges of 
the nodes in categories 1-4.

I'm guessing that the "getPool()" function in 
llvm-poolalloc/include/poolalloc/PoolAllocate.h will return NULL if the 
DSNode is in categories 3 or 5, will return a pointer to the Instruction 
that created the pool for category 2, will return a pointer to the 
global Value representing the pool for category 1, and will return a 
pointer to the pool's Argument for category 4 -- but those are really 
only guesses, and I'd very much appreciate confirmation that I guessed 
right :)

Thanks in advance for your help,
--Patrick


From anton at korobeynikov.info  Mon Jun  8 14:29:21 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Tue, 9 Jun 2009 01:29:21 +0400
Subject: [LLVMdev] Structure alignment
In-Reply-To: <20090608205320.6174.qmail@hm885.locaweb.com.br>
References: <mailman.3.1244480402.31578.llvmdev@cs.uiuc.edu>
	<20090608205320.6174.qmail@hm885.locaweb.com.br>
Message-ID: <b087fca00906081429q3b4f8ec5p9fd9ffb19842f74a@mail.gmail.com>

Hello

> %FIRSTSTRU = type { i32,  double, i32, i8* }
>
> struct  {
>        int                             var1;
>        double                  var2;
>        int                             var3;
>        char    *var4;
> }firstStru ;
LLVM type is not equivalent to mentioned C struct type. You need to
insert padding field into LLVM type.

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



From robert at muth.org  Mon Jun  8 14:42:38 2009
From: robert at muth.org (robert muth)
Date: Mon, 8 Jun 2009 17:42:38 -0400
Subject: [LLVMdev] patch for llc/ARM: added mechanism to move switch
	tables from .text -> .data; also cleanup and documentation
In-Reply-To: <C2EC9000-8447-42CB-B3CD-5DB1652C356F@apple.com>
References: <8e3491100906021826p4530f341xbb168d260c21342e@mail.gmail.com>
	<0453D1AB-FA5D-4947-BE50-02223AB8955B@apple.com>
	<8e3491100906070659k481580afk2d562a6c4a21a2a4@mail.gmail.com>
	<C2EC9000-8447-42CB-B3CD-5DB1652C356F@apple.com>
Message-ID: <8e3491100906081442l3417b3e9nf3abeda39f8f2514@mail.gmail.com>

On Sun, Jun 7, 2009 at 11:53 PM, Evan Cheng <evan.cheng at apple.com> wrote:
>
> On Jun 7, 2009, at 6:59 AM, robert muth wrote:
>
>> On Sat, Jun 6, 2009 at 4:51 PM, Evan Cheng<evan.cheng at apple.com>
>> wrote:
>>> +cl::opt<std::string> FlagJumpTableSection("jumptable-section",
>>> +                                           cl::init(".data.jtab"));
>>> +
>>
>> I thought it would be nice to group all the jumptables together.
>> But as long as it stays configurable, I am fine to change the default
>> to ".data".
>
> There is already a TargetAsmInfo::JumpTableDataSection. Why not just
> use that?

Nice find. I will use that and possible change the current setting,
".const", if it does not work,

>>
>>> Is this necessary? Why not just put it in the normal data section?
>>> Also "outline" jumptable seems like a strange term. Can you think of
>>> something else?
>>
>>
>> Yes, that is a tough one. How about "NonInline" instead.
>
> Or "OutOfLine"?

That works for me.

> Please add a test case as well. Thanks,

I am not sure how to go about testing.
I have  a script that compiles a bunch of test
programs (gnu c torture test, etc.) and then runs the executables
on qemu.  I run this script with and without my flags and
make sure that I do not introduce any new problems
-- there are currently plenty of vararg issues.

I was thinking of sending this script to the list
or maybe checking it into the llvm tree.

The key is that whatever tests there are they should just
be run with and without the new flag.
How do you run backend tests?

Robert




> Evan
>
>>
>> Robert
>>
>>> Thanks,
>>> Evan
>>>
>>> Sent from my iPhone
>>> On Jun 2, 2009, at 6:26 PM, robert muth <robert at muth.org> wrote:
>>>
>>> Hi:
>>>
>>> This is my first patch submission. Hopefully, this is the proper the
>>> protocol.
>>> Attached is a patch for the llc ARM backend:
>>>
>>> Added mechanism to generate switch table in a data section
>>> rather than having it interleaved with the code.
>>> This is controlled by command line flags and off by default.
>>> Also, tried to document and improve the code where I modified it.
>>>
>>> Robert
>>>
>>> <llc.patch.txt>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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 arplynn at gmail.com  Mon Jun  8 14:43:12 2009
From: arplynn at gmail.com (Alastair Lynn)
Date: Mon, 8 Jun 2009 22:43:12 +0100
Subject: [LLVMdev] How to stop symbol searching without aborting
In-Reply-To: <200906080634.02949.bobby@sharedrealm.com>
References: <421B2CED-8DC3-419E-8ACF-CB6643164214@gmail.com>
	<200906080634.02949.bobby@sharedrealm.com>
Message-ID: <F00BF0C9-41C1-4E2B-AB45-7830DC6749E1@gmail.com>

Hi Robert-

I notice that llvm-lua requires LLVM 2.4 rather than anything recent -  
are there any plans to upgrade?

Alastair

On 8 Jun 2009, at 14:34, Robert G. Jakabosky wrote:

>
> Have you tried llvm-lua?  It adds JIT & static compiling support to  
> the Lua VM
> using LLVM as the backend.  I just released version 1.0 about a week  
> ago.
>
> The project website is here:
> http://code.google.com/p/llvm-lua/
>
> On Friday 05, Marcus Zetterquist wrote:
>> Hi!
>>
>>
>> Today we use Lua to let 3rd party developers add driver-like modules
>> to our application.
>>
>> The advantages to using Lua compared to DLL:s etc. are that:
>>
>> 1) the same driver binary can be used on all OS:es and processor
>> architectures etc.
>>
>> 2) We can provide a small API to the Lua drivers and they _cannot_
>> call any other external functions.
>>
>> 3) A buggy driver cannot crash our application. (Almost true  
>> statement.)
>>
>>
>> I'm looking into using LLVM and the bitcode format for this instead.
>> The additional, very important advantages are:
>>
>> 4) 3rd parties can port existing (huge amounts of) C / C++ code much
>> easier - no need to rewrite all code in Lua.
>>
>> 5) Performance. We will use the LLVM JIT.
>>
>>
>> Problem: I can't figure out how to do (2) with the LLVM JIT.
>>
>> It is very important that the driver does not have access to any  
>> other
>> function in the application except those I provide. It's not OK for
>> our application to abort if a driver calls an undefined function - I
>> want to just disable _that driver_ in that event.
>>
>> I can use DisableSymbolSearching() but that causes application to
>> abort for unknown symbols.
>>
>>
>> Please advice!
>>
>>
>> /Marcus
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
> -- 
> Robert G. Jakabosky
> _______________________________________________
> 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: 3912 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090608/98702b6d/attachment.bin>

From malloc at inode.at  Mon Jun  8 16:48:28 2009
From: malloc at inode.at (Marius Wachtler)
Date: Tue, 9 Jun 2009 01:48:28 +0200
Subject: [LLVMdev] Call to address 0 gets removed
Message-ID: <3838f7f10906081648l6397db7v3e369d551b8b54e8@mail.gmail.com>

Hello

If I optimize (opt -std-compile-opts ) the following .ll

; ModuleID = 'call0.ll'
target datalayout =
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
target triple = "i386-mingw32"

define i32 @t(i32 %a) nounwind {
entry:
    %0 = tail call i32 inttoptr (i32 0 to i32 (i32)*)(i32 %a) nounwind
    ; <i32> [#uses=1]
    ret i32 %0
}

The call to address 0 gets removed.

define i32 @t(i32 %a) noreturn nounwind readnone {
entry:
    unreachable
}

How can I prevent that the call is removed, without making the function addr
volatile?
Does anyone know which optimization removes it?

Thanks,
Marius Wachtler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090609/14641775/attachment.html>

From dalej at apple.com  Mon Jun  8 17:03:25 2009
From: dalej at apple.com (Dale Johannesen)
Date: Mon, 8 Jun 2009 17:03:25 -0700
Subject: [LLVMdev] Call to address 0 gets removed
In-Reply-To: <3838f7f10906081648l6397db7v3e369d551b8b54e8@mail.gmail.com>
References: <3838f7f10906081648l6397db7v3e369d551b8b54e8@mail.gmail.com>
Message-ID: <A5048CAD-4761-4F76-8FFE-C7DC895F0A2D@apple.com>


On Jun 8, 2009, at 4:48 PMPDT, Marius Wachtler wrote:

> Hello
>
> If I optimize (opt -std-compile-opts ) the following .ll
>
> ; ModuleID = 'call0.ll'
> target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32- 
> i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64- 
> f80:32:32"
> target triple = "i386-mingw32"
>
> define i32 @t(i32 %a) nounwind {
> entry:
>     %0 = tail call i32 inttoptr (i32 0 to i32 (i32)*)(i32 %a)  
> nounwind        ; <i32> [#uses=1]
>     ret i32 %0
> }
>
> The call to address 0 gets removed.
>
> define i32 @t(i32 %a) noreturn nounwind readnone {
> entry:
>     unreachable
> }
>
> How can I prevent that the call is removed, without making the  
> function addr volatile?
> Does anyone know which optimization removes it?

Calling 0 is undefined behavior; the optimizer is within its rights to  
remove this.  Why do you want to call 0?



From bobby at sharedrealm.com  Mon Jun  8 20:21:44 2009
From: bobby at sharedrealm.com (Robert G. Jakabosky)
Date: Mon, 8 Jun 2009 20:21:44 -0700
Subject: [LLVMdev] How to stop symbol searching without aborting
In-Reply-To: <F00BF0C9-41C1-4E2B-AB45-7830DC6749E1@gmail.com>
References: <421B2CED-8DC3-419E-8ACF-CB6643164214@gmail.com>
	<200906080634.02949.bobby@sharedrealm.com>
	<F00BF0C9-41C1-4E2B-AB45-7830DC6749E1@gmail.com>
Message-ID: <200906082021.44357.bobby@sharedrealm.com>


On Monday 08, Alastair Lynn wrote:
> Hi Robert-
>
> I notice that llvm-lua requires LLVM 2.4 rather than anything recent -
> are there any plans to upgrade?

Sorry I forgot to update the projects home page.
Version 1.0 will work with LLVM 2.5 and should still work with 2.4 (I haven't 
tested against 2.4 recently so it might not work any more).  Also there is a 
branch "llvm-svn" that works with the SVN copy of LLVM as of a few days ago.


-- 
Robert G. Jakabosky


From criswell at uiuc.edu  Mon Jun  8 21:54:55 2009
From: criswell at uiuc.edu (John Criswell)
Date: Mon, 08 Jun 2009 22:54:55 -0600
Subject: [LLVMdev] Pool Allocation and DSA
In-Reply-To: <4A2D8249.3090604@cs.uiuc.edu>
References: <4A2D8249.3090604@cs.uiuc.edu>
Message-ID: <4A2DEB1F.8080405@uiuc.edu>

Patrick Alexander Simmons wrote:
> I don't really have a specific question, but, as I've been looking 
> through pool allocation and the DS graphs extensively, I wanted to 
> verify that my understanding of the representations used is correct.  
> Therefore, I'm summarizing my understanding below (which, if it's 
> correct, may hopefully be helpful to others).  I would appreciate if 
> someone who understands pool allocation well would comment on whether 
> I'm right in my understanding.
>
> After pool allocation runs, each Function is associated with a DS 
> graph.  Each node in a Function's DS graph falls into one of the 
> following categories:
>
> 1.  The node corresponds to a global pool.
> 2.  The node corresponds to a pool created by the Function.
> 3.  The node corresponds to a formal parameter passed to the function 
> (and is the result of conservatively folding all possible actual 
> parameters that may be passed to the function).
> 4.  The node corresponds to a pool parameter passed to the Function.
> 5.  The node is not in categories 1-4, in which case it must be pointed 
> to by some other pool which either is in categories 1-4 or is pointed to 
> by some other node, for which the same condition must hold.  That is to 
> say, all nodes in the graph must be reachable by following the edges of 
> the nodes in categories 1-4.
>   
I don't believe this is correct, or, at the very least, you are using 
confusing terminology.

First, DSA and Pool Allocation are two completely different things.  DSA 
is a points-to analysis.  It creates a graph (one per function + 1 
global graph for global variables) where each node represents a set of 
memory objects and the edges represent pointers within one memory object 
that point to another memory object (i.e. if node A points to node B, 
that means a field in one of the objects in node A points to an object 
in node B).  The DSGraph also contains a ScalarMap which maps LLVM 
Values to nodes in the graph (these nodes are called DSNodes).  DSA is 
somewhat special because it attempts to disambiguate different linked 
data structures within programs (hence the name Data Structure Analysis, 
or DSA).

Automatic Pool Allocation (APA) is a transform that is built on top of 
DSA.  It uses the points-to graphs computed by DSA to group allocations 
into various pools.  The original idea was to place nodes of the same 
pointer-based data structure into the same pool to get better cache 
locality.  The pools that Automatic Pool Allocation creates can either 
be global variables or local alloca'ed memory, depending upon how long 
the pool must be alive, what heuristics Automatic Pool Allocation is 
using, and whether the DSA results are context sensitive or 
insensitive.  When a pool is created based on context sensitive results, 
it is stack allocated and passed around as an argument to functions.

However, Automatic Pool Allocation has another use beyond improving 
performance.  It turns out that if you allocate memory based on the 
points-to analysis results, you can speed up run-time checks for memory 
safety.  This leads to SAFECode: a transform built on top of Automatic 
Pool Allocation that adds additional information to each pool to 
implement fast run-time checks.

Transforms like SAFECode need to know the mapping between the pointers 
in a program and the pool in which those pointers were assigned (more 
accurately, the pool in which the memory objects pointed to by those 
pointers were allocated).  The easiest way to do this was to have 
SAFECode query Automatic Pool Allocation.  This is, therefore, the 
purpose of getPool(): it allows other LLVM passes to ask Automatic Pool 
Allocation what pool a particular LLVM Value lives in.  The pool is 
returned as an LLVM Value *.  Depending on whether the pool is global, 
stack allocated, or passed into the function determines whether it is an 
LLVM GlobalVariable *, LLVM AllocaInst *, or LLVM Argument *.

-- John T.

> I'm guessing that the "getPool()" function in 
> llvm-poolalloc/include/poolalloc/PoolAllocate.h will return NULL if the 
> DSNode is in categories 3 or 5, will return a pointer to the Instruction 
> that created the pool for category 2, will return a pointer to the 
> global Value representing the pool for category 1, and will return a 
> pointer to the pool's Argument for category 4 -- but those are really 
> only guesses, and I'd very much appreciate confirmation that I guessed 
> right :)
>
> Thanks in advance for your help,
> --Patrick
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   



From Vasudev.Negi at microchip.com  Mon Jun  8 23:23:32 2009
From: Vasudev.Negi at microchip.com (Vasudev.Negi at microchip.com)
Date: Mon, 8 Jun 2009 23:23:32 -0700
Subject: [LLVMdev] debug information for functions
In-Reply-To: <352a1fb20906081032y503ebb77icc9b4e7212906d54@mail.gmail.com>
References: <F536B7C316F9474E9F7091239725AC9A02977F0D@CHN-CL-MAIL01.mchp-main.com>
	<352a1fb20906081032y503ebb77icc9b4e7212906d54@mail.gmail.com>
Message-ID: <F536B7C316F9474E9F7091239725AC9A02978098@CHN-CL-MAIL01.mchp-main.com>

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
On Behalf Of Devang Patel
Sent: Monday, June 08, 2009 11:03 PM
To: LLVM Developers Mailing List
Subject: Re: [LLVMdev] debug information for functions

On Mon, Jun 8, 2009 at 3:25 AM, <Vasudev.Negi at microchip.com> wrote:
>
> I get .bc files for foo.c and foo.bc through clang. Now I run llvm-ld
> with -disable-opt for foo.bc and goo.bc. In the resulting .bc files,
one
> of the two functions fun, is renamed to fun<number>. There are two
> llvm.dbg.subprogram descriptors created for the two fun functions.
Both
> have name foo . So there is no way to know which descriptor represents
> which function. I am trying to get this information in assembly
printer.

What is the use of this info ? The descriptor includes enough location
info (thru func.start) and the display name for static functions.

-
Devang

We are not using Dwarf writer. We are emitting debug info in coff
format. I need the file in which function is defined to emit .file
directive. MachineFunction has DefaultDebugLoc but it gets set only in
the case of -O0.
I can get the DebugLoc from machine instruction but that will be an ugly
way to do it.





From baldrick at free.fr  Tue Jun  9 00:14:10 2009
From: baldrick at free.fr (Duncan Sands)
Date: Tue, 09 Jun 2009 09:14:10 +0200
Subject: [LLVMdev] Structure alignment
In-Reply-To: <20090608205320.6174.qmail@hm885.locaweb.com.br>
References: <mailman.3.1244480402.31578.llvmdev@cs.uiuc.edu>
	<20090608205320.6174.qmail@hm885.locaweb.com.br>
Message-ID: <4A2E0BC2.30006@free.fr>

Manoel Teixeira wrote:
> %FIRSTSTRU = type { i32,  double, i32, i8* }
> 
> struct  {
> 	int				var1;
> 	double			var2;
> 	int				var3;
> 	char	*var4;
> }firstStru ;
> 
> Could someone help? 
> If, running a application in windows with MSVC,  I allocate a memmory buffer and call a LLVM 
> function with such buffer, there's a structure alignment problem.
> If the LLVM function call a C function using the same buffer, it runs fine.
> Any ideas?

I think it's best if you send the bitcode produced by llvm-gcc/clang.

Ciao,

Duncan.


From schlie at comcast.net  Tue Jun  9 10:02:24 2009
From: schlie at comcast.net (Paul Schlie)
Date: Tue, 09 Jun 2009 13:02:24 -0400
Subject: [LLVMdev]  Call to address 0 gets removed
Message-ID: <C6540DE0.165B5%schlie@comcast.net>

> Dale Johannesen wrote:
>> Marius Wachtler wrote:
>> ...
>> The call to address 0 gets removed.
>>
>> define i32 @t(i32 %a) noreturn nounwind readnone {
>> entry:
>>     unreachable
>> }
>>
>> How can I prevent that the call is removed, without making the
>> function addr volatile?
>> Does anyone know which optimization removes it?
>
> Calling 0 is undefined behavior; the optimizer is within its rights to
> remove this.  Why do you want to call 0?

Although a C translation unit may arguably not assign a correspondingly
defined function as having a pointer value (address) comparing equal to
((void *) 0); it's not clear that the standard forbids the invocation of
such a function, nor does it seem like a good idea to silently strip any
such invocations especially if allowed to be specified; as to do so would
seemingly only mask potentially legitimate problems, and/or prevent that
intended from being performed although potentially relying on an undefined
behavior.

(As for example, it's not hard to imagine that it may be desirable to allow
a machine which may trap such calls to do, and/or to allow the invocation of
some otherwise specified behavior although considered undefined by standard
itself.)




From dalej at apple.com  Tue Jun  9 10:36:11 2009
From: dalej at apple.com (Dale Johannesen)
Date: Tue, 9 Jun 2009 10:36:11 -0700
Subject: [LLVMdev] Call to address 0 gets removed
In-Reply-To: <C6540DE0.165B5%schlie@comcast.net>
References: <C6540DE0.165B5%schlie@comcast.net>
Message-ID: <12BD2949-2653-4AF7-946E-F04257B3180A@apple.com>


On Jun 9, 2009, at 10:02 AMPDT, Paul Schlie wrote:

>> Dale Johannesen wrote:
>>> Marius Wachtler wrote:
>>> ...
>>> The call to address 0 gets removed.
>>>
>>> define i32 @t(i32 %a) noreturn nounwind readnone {
>>> entry:
>>>    unreachable
>>> }
>>>
>>> How can I prevent that the call is removed, without making the
>>> function addr volatile?
>>> Does anyone know which optimization removes it?
>>
>> Calling 0 is undefined behavior; the optimizer is within its rights  
>> to
>> remove this.  Why do you want to call 0?
>
> Although a C translation unit may arguably not assign a  
> correspondingly
> defined function as having a pointer value (address) comparing equal  
> to
> ((void *) 0);

Nothing arguable about it, see C99 6.3.2.3

> it's not clear that the standard forbids the invocation of  such a  
> function

No such function can exist.  I don't think the standard forbids you to  
call 0, but it makes calling 0 undefined behavior ("behavior, upon use  
of a nonportable or erroneous program construct or of erroneous  
data"), since there can't possibly be a valid function there.

> nor does it seem like a good idea to silently strip any
> such invocations especially if allowed to be specified; as to do so  
> would
> seemingly only mask potentially legitimate problems, and/or prevent  
> that
> intended from being performed although potentially relying on an  
> undefined
> behavior.
>
> (As for example, it's not hard to imagine that it may be desirable  
> to allow
> a machine which may trap such calls to do, and/or to allow the  
> invocation of
> some otherwise specified behavior although considered undefined by  
> standard
> itself.)

In general, a C compiler is not the right tool to use for  
functionality outside the C language, so I'm not inclined to be  
sympathetic to this line of reasoning.



From dag at cray.com  Tue Jun  9 12:00:24 2009
From: dag at cray.com (David Greene)
Date: Tue, 9 Jun 2009 14:00:24 -0500
Subject: [LLVMdev] Regular Expressions
In-Reply-To: <4A2E2CE5.7070407@gmail.com>
References: <200906081700.n58H0Zvi022899@zion.cs.uiuc.edu>
	<f126fae00906090227p1af4713h63979e807b6edbeb@mail.gmail.com>
	<4A2E2CE5.7070407@gmail.com>
Message-ID: <200906091400.25004.dag@cray.com>

On Tuesday 09 June 2009 04:35, Török Edwin wrote:
> On 2009-06-09 12:27, Howard Su wrote:
> > This change break the MSVC build since no regex by default in Windows
> > MSVC platform.
>
> Perhaps we should add a regex implementation to lib/System?

That's potentially a lot of work.  I started looking at it and it would
involve hiding the OpenBSD library under some other lib/System facade.
Designing that facade takes time and we probably won't get it right
the first or second time.

Another option is to just provide the OpenBSD regex code as an optional
library that gets compiled and linked for MSVC systems.  I'm not at all
familiar with MSVC build procedures so I don't know how involved that is.

The advantage to the second approach is that we keep the POSIX interfaces
in the rest of the LLVM code, we don't have to design another set of
interfaces and we just use the OpenBSD library when we have to.

Thoughts?

                               -Dave



From deeppatel1987 at gmail.com  Tue Jun  9 12:12:50 2009
From: deeppatel1987 at gmail.com (Sandeep Patel)
Date: Tue, 9 Jun 2009 12:12:50 -0700
Subject: [LLVMdev] Regular Expressions
In-Reply-To: <200906091400.25004.dag@cray.com>
References: <200906081700.n58H0Zvi022899@zion.cs.uiuc.edu>
	<f126fae00906090227p1af4713h63979e807b6edbeb@mail.gmail.com>
	<4A2E2CE5.7070407@gmail.com> <200906091400.25004.dag@cray.com>
Message-ID: <305d6f60906091212w425ebd28pba0cc449feb193ba@mail.gmail.com>

On Tue, Jun 9, 2009 at 12:00 PM, David Greene<dag at cray.com> wrote:
> On Tuesday 09 June 2009 04:35, Török Edwin wrote:
>> On 2009-06-09 12:27, Howard Su wrote:
>> > This change break the MSVC build since no regex by default in Windows
>> > MSVC platform.
>>
>> Perhaps we should add a regex implementation to lib/System?
>
> That's potentially a lot of work.  I started looking at it and it would
> involve hiding the OpenBSD library under some other lib/System facade.
> Designing that facade takes time and we probably won't get it right
> the first or second time.
>
> Another option is to just provide the OpenBSD regex code as an optional
> library that gets compiled and linked for MSVC systems.  I'm not at all
> familiar with MSVC build procedures so I don't know how involved that is.
>
> The advantage to the second approach is that we keep the POSIX interfaces
> in the rest of the LLVM code, we don't have to design another set of
> interfaces and we just use the OpenBSD library when we have to.

<http://www.laurikari.net/tre/> looks somewhat promising as a
POSIX-compatible regex library with a suitable license.

deep



From gohman at apple.com  Tue Jun  9 12:34:42 2009
From: gohman at apple.com (Dan Gohman)
Date: Tue, 9 Jun 2009 12:34:42 -0700
Subject: [LLVMdev] Regular Expressions
In-Reply-To: <200906091400.25004.dag@cray.com>
References: <200906081700.n58H0Zvi022899@zion.cs.uiuc.edu>
	<f126fae00906090227p1af4713h63979e807b6edbeb@mail.gmail.com>
	<4A2E2CE5.7070407@gmail.com> <200906091400.25004.dag@cray.com>
Message-ID: <FC9FD7DE-415E-4273-A4C0-B03724119620@apple.com>

Can you describe what problem you're trying to solve here?  Does it
really need Regular Expressions?

Dan



From gohman at apple.com  Tue Jun  9 12:35:05 2009
From: gohman at apple.com (Dan Gohman)
Date: Tue, 9 Jun 2009 12:35:05 -0700
Subject: [LLVMdev] Tablegen question
In-Reply-To: <68c4c3e20906081325r193ade4co57841c1f3ed08842@mail.gmail.com>
References: <68c4c3e20906060947h7cc89277uf41a0d8c9ffabe89@mail.gmail.com>
	<57C38DA176A0A34A9B9F3CCCE33D3C4AFB244D2ECB@FRPAR1CL009.coe.adi.dibcom.com>
	<68c4c3e20906080958y6ed1ad9ay1d9f5ddd4adcfdf2@mail.gmail.com>
	<B96B557C-F46A-49CD-A6DA-7D3092E74E4F@apple.com>
	<68c4c3e20906081325r193ade4co57841c1f3ed08842@mail.gmail.com>
Message-ID: <DA634290-3EFD-4ABA-9474-FEFF1EE7E76E@apple.com>


On Jun 8, 2009, at 1:25 PM, Manjunath Kudlur wrote:


> Dan,
>
>
>> In general, it's a design goal to structure CodeGen features as
>>
>> target-independent code parameterized with target-specific data.
>>
>> The degree to which this goal is met in LLVM CodeGen features today
>>
>> varies, but features that have been implemented using TableGen have
>>
>> been relatively successful.
>>
>
> Can you give an example of a relatively successful instance where
> Tablegen was used to implement something specific for a target?

All of the tablegen backends work this way. As you mentioned,
there are no target-specific tablegen backends at present.

The underlying observation here is that features are never
fundamentally "specific for a target". For example, a mapping
between vector opcodes and associated scalar opcodes could
reasonably be made on many architectures. Even
load-balancing between functional units on a processor is a
target-independent concept, with details like the number and
nature of the functional units being target-dependent.

Dan



From dag at cray.com  Tue Jun  9 12:37:40 2009
From: dag at cray.com (David Greene)
Date: Tue, 9 Jun 2009 14:37:40 -0500
Subject: [LLVMdev] Regular Expressions
In-Reply-To: <305d6f60906091212w425ebd28pba0cc449feb193ba@mail.gmail.com>
References: <200906081700.n58H0Zvi022899@zion.cs.uiuc.edu>
	<200906091400.25004.dag@cray.com>
	<305d6f60906091212w425ebd28pba0cc449feb193ba@mail.gmail.com>
Message-ID: <200906091437.41033.dag@cray.com>

On Tuesday 09 June 2009 14:12, Sandeep Patel wrote:
r with MSVC build procedures so I don't know how involved that is.
> >
> > The advantage to the second approach is that we keep the POSIX interfaces
> > in the rest of the LLVM code, we don't have to design another set of
> > interfaces and we just use the OpenBSD library when we have to.
>
> <http://www.laurikari.net/tre/> looks somewhat promising as a
> POSIX-compatible regex library with a suitable license.

We've talked about http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/regex/
as well.  Is there any reason to prefer one over the other?

I'm testing an integration of the OpenBSD code right now.  I can't test a
Windows build, though.  So how should we go about doing that?  I have the
autoconf and (I think) cmake work done, but I have no way of fully testing
it.  Should I just check it in and let Windows users give it a try?

                                    -Dave


From dag at cray.com  Tue Jun  9 12:39:18 2009
From: dag at cray.com (David Greene)
Date: Tue, 9 Jun 2009 14:39:18 -0500
Subject: [LLVMdev] Regular Expressions
In-Reply-To: <FC9FD7DE-415E-4273-A4C0-B03724119620@apple.com>
References: <200906081700.n58H0Zvi022899@zion.cs.uiuc.edu>
	<200906091400.25004.dag@cray.com>
	<FC9FD7DE-415E-4273-A4C0-B03724119620@apple.com>
Message-ID: <200906091439.18446.dag@cray.com>

On Tuesday 09 June 2009 14:34, Dan Gohman wrote:
> Can you describe what problem you're trying to solve here?  Does it
> really need Regular Expressions?

Yes.  I want TableGen to be able to infer lots of stuff programmatically.
This helps tremendously when specifying things like, oh, AVX.  :)

We could invent our own pattern matching syntax, but why?

                                -Dave


From nunoplopes at sapo.pt  Tue Jun  9 13:02:08 2009
From: nunoplopes at sapo.pt (Nuno Lopes)
Date: Tue, 9 Jun 2009 21:02:08 +0100
Subject: [LLVMdev] Regular Expressions
References: <200906081700.n58H0Zvi022899@zion.cs.uiuc.edu><f126fae00906090227p1af4713h63979e807b6edbeb@mail.gmail.com><4A2E2CE5.7070407@gmail.com>
	<200906091400.25004.dag@cray.com>
Message-ID: <06F21D74313F4100BDB77D8158D7FC29@PC3EE1F19287>

> On Tuesday 09 June 2009 04:35, Török Edwin wrote:
> > On 2009-06-09 12:27, Howard Su wrote:
> > > This change break the MSVC build since no regex by default in Windows
> > > MSVC platform.
> >
> > Perhaps we should add a regex implementation to lib/System?
>
> That's potentially a lot of work.  I started looking at it and it would
> involve hiding the OpenBSD library under some other lib/System facade.
> Designing that facade takes time and we probably won't get it right
> the first or second time.

I guess the standard regex library is PCRE (http://pcre.org). It has its own 
api, but it also supports the POSIX interface. The regex syntax is Perl 
compatible.
We bundle this library in the PHP core and it works pretty well. It compiles 
everywhere and the maintenance burden is close to zero.

Nuno 



From keveman at gmail.com  Tue Jun  9 13:16:39 2009
From: keveman at gmail.com (Manjunath Kudlur)
Date: Tue, 9 Jun 2009 13:16:39 -0700
Subject: [LLVMdev] Tablegen question
In-Reply-To: <DA634290-3EFD-4ABA-9474-FEFF1EE7E76E@apple.com>
References: <68c4c3e20906060947h7cc89277uf41a0d8c9ffabe89@mail.gmail.com>
	<57C38DA176A0A34A9B9F3CCCE33D3C4AFB244D2ECB@FRPAR1CL009.coe.adi.dibcom.com>
	<68c4c3e20906080958y6ed1ad9ay1d9f5ddd4adcfdf2@mail.gmail.com>
	<B96B557C-F46A-49CD-A6DA-7D3092E74E4F@apple.com>
	<68c4c3e20906081325r193ade4co57841c1f3ed08842@mail.gmail.com>
	<DA634290-3EFD-4ABA-9474-FEFF1EE7E76E@apple.com>
Message-ID: <68c4c3e20906091316v4df559aex1408c11d8f515f09@mail.gmail.com>

> All of the tablegen backends work this way. As you mentioned,
> there are no target-specific tablegen backends at present.
>
> The underlying observation here is that features are never
> fundamentally "specific for a target". For example, a mapping
> between vector opcodes and associated scalar opcodes could
> reasonably be made on many architectures. Even
> load-balancing between functional units on a processor is a
> target-independent concept, with details like the number and
> nature of the functional units being target-dependent.

Sorry to be such a pest, but I am still trying to understand the usage
model for tablegen. Are you saying it is not a good idea to write a
tablegen backend for something very specific to a target? The examples
I gave happen to be applicable to many targets. But the usage depends
on AN implementation of codegen for a target, no? I mean, I could
choose to put the related scalar instruction in a field with a
specific name in the myInst class in the .td file, and would want to
populate a data structure with a specific name in my C++ code. The
tablegen backend should "know" the names of both the field in the .td
file and the name of the data structure. How can I make this generic?

Thanks,
Manjunath


From dag at cray.com  Tue Jun  9 13:18:21 2009
From: dag at cray.com (David Greene)
Date: Tue, 9 Jun 2009 15:18:21 -0500
Subject: [LLVMdev] Regular Expressions
In-Reply-To: <06F21D74313F4100BDB77D8158D7FC29@PC3EE1F19287>
References: <200906081700.n58H0Zvi022899@zion.cs.uiuc.edu>
	<200906091400.25004.dag@cray.com>
	<06F21D74313F4100BDB77D8158D7FC29@PC3EE1F19287>
Message-ID: <200906091518.21757.dag@cray.com>

On Tuesday 09 June 2009 15:02, Nuno Lopes wrote:
> > On Tuesday 09 June 2009 04:35, Török Edwin wrote:
> > > On 2009-06-09 12:27, Howard Su wrote:
> > > > This change break the MSVC build since no regex by default in Windows
> > > > MSVC platform.
> > >
> > > Perhaps we should add a regex implementation to lib/System?
> >
> > That's potentially a lot of work.  I started looking at it and it would
> > involve hiding the OpenBSD library under some other lib/System facade.
> > Designing that facade takes time and we probably won't get it right
> > the first or second time.
>
> I guess the standard regex library is PCRE (http://pcre.org). It has its
> own api, but it also supports the POSIX interface. The regex syntax is Perl
> compatible.
> We bundle this library in the PHP core and it works pretty well. It
> compiles everywhere and the maintenance burden is close to zero.

That's a big piece of software.  The OpenBSD version is much smaller.  I have
the OpenBSD version integrated so I'll intend to use that unless someone tells
me we can't for some reason.

Testing under Linux went fine, but that's to be expected.

The main issue with pcre is that it's meant to be built as a standalone 
library.  While I agree with that architecture, it doesn't fit well into
LLVM's libSystem notion.  I don't know if we want to get into the business
of configuring and building external libraries as part of the LLVM build
process.  At least I know *I* don't want to do it.  Others should feel 
free.  :)

Really, we should be using TR1 but not all compilers are there yet.

BTW, is there a process for dropping compiler support?  Eventually most 
compilers will have TR1 except for very old versions.  It's not feasible
to support all of those crufty compilers forever.

                                     -Dave



From manoel at fonetica.com.br  Tue Jun  9 13:35:52 2009
From: manoel at fonetica.com.br (=?ISO-8859-1?Q?Manoel=20Teixeira?=)
Date: Tue,  9 Jun 2009 17:35:52 -0300
Subject: [LLVMdev] Structure alignment
In-Reply-To: <mailman.1.1244566801.26146.llvmdev@cs.uiuc.edu>
References: <mailman.1.1244566801.26146.llvmdev@cs.uiuc.edu>
Message-ID: <20090609203552.24620.qmail@hm885.locaweb.com.br>


Hi,
It's not ok yet.
When a C function calls a LLVM function, or a LLVM function calls a C function, the offset of the variables are wrong.
When a don't mix LLVM with C, it's ok, but I need call extern functions using structs.
Ciao
 
Manoel

Subject: Re: [LLVMdev] Structure alignment
To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
Message-ID:
    <f5aa3e9b0906081415oa706eadh21a7814c0f95e006 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Jun 8, 2009 at 1:53 PM, Manoel Teixeira<manoel at fonetica.com.br> wrote:
>
> %FIRSTSTRU = type { i32, ?double, i32, i8* }
>
> struct ?{
> ? ? ? ?int ? ? ? ? ? ? ? ? ? ? ? ? ? ? var1;
> ? ? ? ?double ? ? ? ? ? ? ? ? ?var2;
> ? ? ? ?int ? ? ? ? ? ? ? ? ? ? ? ? ? ? var3;
> ? ? ? ?char ? ?*var4;
> }firstStru ;
>
> Could someone help?
> If, running a application in windows with MSVC, ?I allocate a memmory buffer and call a LLVM
> function with such buffer, there's a structure alignment problem.
> If the LLVM function call a C function using the same buffer, it runs fine.
> Any ideas?

You're probably passing in the wrong string to the TargetData; try
something like the following:
target datalayout =
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"

-Eli


From nicolas at capens.net  Tue Jun  9 14:58:19 2009
From: nicolas at capens.net (Nicolas Capens)
Date: Tue, 9 Jun 2009 23:58:19 +0200
Subject: [LLVMdev] [Patch] Fix SSE2 packing intrinsics return type
Message-ID: <000601c9e94d$666af910$3340eb30$@net>

Hi all,

 

Please consider committing the attached patch. I believe the SSE2 packsswb,
packssdw and packuswb intrinsics have an incorrect return type.

 

Thanks,

 

Nicolas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090609/85ed0b5e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PackSSE2.patch
Type: application/octet-stream
Size: 1200 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090609/85ed0b5e/attachment.obj>

From eli.friedman at gmail.com  Tue Jun  9 17:56:57 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Tue, 9 Jun 2009 17:56:57 -0700
Subject: [LLVMdev] [Patch] Fix SSE2 packing intrinsics return type
In-Reply-To: <000601c9e94d$666af910$3340eb30$@net>
References: <000601c9e94d$666af910$3340eb30$@net>
Message-ID: <f5aa3e9b0906091756x3227fa27i7923d8617788e7df@mail.gmail.com>

On Tue, Jun 9, 2009 at 2:58 PM, Nicolas Capens<nicolas at capens.net> wrote:
> Please consider committing the attached patch. I believe the SSE2 packsswb,
> packssdw and packuswb intrinsics have an incorrect return type.

If we really wanted to do this, an AutoUpgrade patch would be
necessary for backwards-compatibility.  I'm not sure it's worth
bothering.

-Eli


From mcheva at cs.mcgill.ca  Tue Jun  9 18:15:00 2009
From: mcheva at cs.mcgill.ca (Nyx)
Date: Tue, 9 Jun 2009 18:15:00 -0700 (PDT)
Subject: [LLVMdev]  Phi Node Question
Message-ID: <23953992.post@talk.nabble.com>


I'm designing a JIT compiler and I have a potentially problematic situation.
The functions I compile may need to create/access an object during their
execution. In the case where this object won't be needed, I'd rather avoid
generating code to creating the object, as this is a slight performance
waste. Unfortunately, it's rather difficult to know whether this will be the
case without actually compiling the functions.

Thus, I have been thinking that I could generate code to create the said
object the first time it is needed by the function's code (during JIT
compilation). I would simply reserve an empty basic block at the start of
the function for this purpose, and insert the code there if needed. If the
object is needed, then I would insert the code to create it, and store a
pointer to it in an llvm::Value object.

Now, the question I have is as follows... If I only define this object once
at the start of the function, do I need to create phi nodes to propagate its
value everywhere, or can I keep using the same llvm::Value object everywhere
in the function, regargless of which basic block I'm currently in? There
will not be a case where this object is defined twice along separate
branches, it will always be defined only once at the start of the function
(entry basic block). However, if I have to create these phi nodes, it would
significantly complicate the addition of code to create the object, as I'd
have to go back and add all the phi nodes.

Thank you for your time,

- Max
-- 
View this message in context: http://www.nabble.com/Phi-Node-Question-tp23953992p23953992.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.



From eli.friedman at gmail.com  Tue Jun  9 18:51:56 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Tue, 9 Jun 2009 18:51:56 -0700
Subject: [LLVMdev] Phi Node Question
In-Reply-To: <23953992.post@talk.nabble.com>
References: <23953992.post@talk.nabble.com>
Message-ID: <f5aa3e9b0906091851u71d8b50eo9f51631b2ebdd40e@mail.gmail.com>

On Tue, Jun 9, 2009 at 6:15 PM, Nyx<mcheva at cs.mcgill.ca> wrote:
> Now, the question I have is as follows... If I only define this object once
> at the start of the function, do I need to create phi nodes to propagate its
> value everywhere, or can I keep using the same llvm::Value object everywhere
> in the function, regargless of which basic block I'm currently in?

If you put an instruction in the entry block, you can use the returned
value directly in every other block in the function; that's the magic
of SSA.  If you're doing something more complicated, like creating a
variable whose value might change over the course of the function, you
can stick an alloca in the entry block, use loads and stores to modify
and access the value, and let the mem2reg pass take care of converting
it into PHI nodes.  You never need to create a PHI node yourself if
you don't want to mess with figuring out how exactly they work.

-Eli


From me22.ca at gmail.com  Tue Jun  9 19:28:37 2009
From: me22.ca at gmail.com (me22)
Date: Tue, 9 Jun 2009 19:28:37 -0700
Subject: [LLVMdev] Call to address 0 gets removed
In-Reply-To: <12BD2949-2653-4AF7-946E-F04257B3180A@apple.com>
References: <C6540DE0.165B5%schlie@comcast.net>
	<12BD2949-2653-4AF7-946E-F04257B3180A@apple.com>
Message-ID: <fa28b9250906091928q1c0b0eb7k60480860fb6ec356@mail.gmail.com>

2009/6/9 Dale Johannesen <dalej at apple.com>:
>
>>
>> Although a C translation unit may arguably not assign a
>> correspondingly
>> defined function as having a pointer value (address) comparing equal
>> to
>> ((void *) 0);
>
> Nothing arguable about it, see C99 6.3.2.3
>
>> it's not clear that the standard forbids the invocation of  such a
>> function
>
> No such function can exist.  I don't think the standard forbids you to
> call 0, but it makes calling 0 undefined behavior ("behavior, upon use
> of a nonportable or erroneous program construct or of erroneous
> data"), since there can't possibly be a valid function there.
>

In C++, my understanding is that the null pointer --
static_cast<void*>(0) -- need not be the pointer whose representation
is all unset bits -- reinterpret_cast<void*>(0) -- and that only
loads/stores/calls/etc on the former are undefined behaviour, as there
may be architectures or programming levels on which referring to
memory address 0 is perfectly reasonable.

Does C99 have such a distinction as well?

~ Scott



From clattner at apple.com  Tue Jun  9 22:15:33 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 9 Jun 2009 22:15:33 -0700
Subject: [LLVMdev] [Patch] Fix SSE2 packing intrinsics return type
In-Reply-To: <f5aa3e9b0906091756x3227fa27i7923d8617788e7df@mail.gmail.com>
References: <000601c9e94d$666af910$3340eb30$@net>
	<f5aa3e9b0906091756x3227fa27i7923d8617788e7df@mail.gmail.com>
Message-ID: <6B8A053E-2BE2-4330-AF33-5D96961A58E5@apple.com>


On Jun 9, 2009, at 5:56 PM, Eli Friedman wrote:

> On Tue, Jun 9, 2009 at 2:58 PM, Nicolas Capens<nicolas at capens.net>  
> wrote:
>> Please consider committing the attached patch. I believe the SSE2  
>> packsswb,
>> packssdw and packuswb intrinsics have an incorrect return type.
>
> If we really wanted to do this, an AutoUpgrade patch would be
> necessary for backwards-compatibility.  I'm not sure it's worth
> bothering.

Did they work before with llvm-gcc?  If not, then don't worry about  
backward compatibility.

-Chris


From baldrick at free.fr  Tue Jun  9 23:42:29 2009
From: baldrick at free.fr (Duncan Sands)
Date: Wed, 10 Jun 2009 08:42:29 +0200
Subject: [LLVMdev] Structure alignment
In-Reply-To: <20090609203552.24620.qmail@hm885.locaweb.com.br>
References: <mailman.1.1244566801.26146.llvmdev@cs.uiuc.edu>
	<20090609203552.24620.qmail@hm885.locaweb.com.br>
Message-ID: <4A2F55D5.2060802@free.fr>

Hi Manoel,

> When a C function calls a LLVM function, or a LLVM function calls a C function, the offset of the variables are wrong.
> When a don't mix LLVM with C, it's ok, but I need call extern functions using structs.

please open a bugreport with a testcase.

Thanks,

Duncan.


From eli.friedman at gmail.com  Wed Jun 10 00:48:15 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Wed, 10 Jun 2009 00:48:15 -0700
Subject: [LLVMdev] [Patch] Fix SSE2 packing intrinsics return type
In-Reply-To: <6B8A053E-2BE2-4330-AF33-5D96961A58E5@apple.com>
References: <000601c9e94d$666af910$3340eb30$@net>
	<f5aa3e9b0906091756x3227fa27i7923d8617788e7df@mail.gmail.com>
	<6B8A053E-2BE2-4330-AF33-5D96961A58E5@apple.com>
Message-ID: <f5aa3e9b0906100048g5c1bca46na60a4a8fc483792@mail.gmail.com>

On Tue, Jun 9, 2009 at 10:15 PM, Chris Lattner<clattner at apple.com> wrote:
>
> On Jun 9, 2009, at 5:56 PM, Eli Friedman wrote:
>
>> On Tue, Jun 9, 2009 at 2:58 PM, Nicolas Capens<nicolas at capens.net>
>> wrote:
>>> Please consider committing the attached patch. I believe the SSE2
>>> packsswb,
>>> packssdw and packuswb intrinsics have an incorrect return type.
>>
>> If we really wanted to do this, an AutoUpgrade patch would be
>> necessary for backwards-compatibility.  I'm not sure it's worth
>> bothering.
>
> Did they work before with llvm-gcc?  If not, then don't worry about
> backward compatibility.

They work just fine as-is due to the rough equivalence of all SSE2
types; it's just not quite clean to use an i16 vector for the return
when the result actually contains i8s.

-Eli



From st at invia.fr  Wed Jun 10 05:37:56 2009
From: st at invia.fr (Sylvere Teissier)
Date: Wed, 10 Jun 2009 14:37:56 +0200
Subject: [LLVMdev] Call to address 0 gets removed
In-Reply-To: <A5048CAD-4761-4F76-8FFE-C7DC895F0A2D@apple.com>
References: <3838f7f10906081648l6397db7v3e369d551b8b54e8@mail.gmail.com>
	<A5048CAD-4761-4F76-8FFE-C7DC895F0A2D@apple.com>
Message-ID: <1244637476.5473.4.camel@vostro-1510.invia>

> Calling 0 is undefined behavior; the optimizer is within its rights to  
> remove this.  Why do you want to call 0?

For example, on embedded platforms you call 0 to do a soft reset.

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



From nicolas at capens.net  Wed Jun 10 05:54:31 2009
From: nicolas at capens.net (Nicolas Capens)
Date: Wed, 10 Jun 2009 14:54:31 +0200
Subject: [LLVMdev] [Patch] Fix SSE2 packing intrinsics return type
In-Reply-To: <f5aa3e9b0906091756x3227fa27i7923d8617788e7df@mail.gmail.com>
References: <000601c9e94d$666af910$3340eb30$@net>
	<f5aa3e9b0906091756x3227fa27i7923d8617788e7df@mail.gmail.com>
Message-ID: <000001c9e9ca$99061cb0$cb125610$@net>

Hi Eli,

What exactly do mean by an AutoUpgrade patch?

I don't see how this could cause any issues with backward compatibility.
People currently using these intrinsics need a bitcast of the result to
avoid an assert, and with the patch applied the bitcast is no longer
necessary.

Cheers,

Nicolas


-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Eli Friedman
Sent: woensdag 10 juni 2009 2:57
To: LLVM Developers Mailing List
Subject: Re: [LLVMdev] [Patch] Fix SSE2 packing intrinsics return type

On Tue, Jun 9, 2009 at 2:58 PM, Nicolas Capens<nicolas at capens.net> wrote:
> Please consider committing the attached patch. I believe the SSE2
packsswb,
> packssdw and packuswb intrinsics have an incorrect return type.

If we really wanted to do this, an AutoUpgrade patch would be
necessary for backwards-compatibility.  I'm not sure it's worth
bothering.

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



From e0325716 at student.tuwien.ac.at  Wed Jun 10 06:03:54 2009
From: e0325716 at student.tuwien.ac.at (Andreas Neustifter)
Date: Wed, 10 Jun 2009 15:03:54 +0200
Subject: [LLVMdev] Problem with llc and ppc64
Message-ID: <4A2FAF3A.6010407@student.tuwien.ac.at>

Hi,

I'm having problem with generating ppc64-assembler code.

First I create ppc64-assembler with llc:

	llc -march=ppc64 gzip.bc -f -o gzip.s

Then I try to compile this with a cross-compiler on x86_64-linux to ppc64-linux:

	.../crosstools/gcc-4.2.4-glibc-2.3.6/powerpc64-unknown-linux-gnu/bin/powerpc64-unknown-linux-gnu-gcc gzip.s

But the compiler gives me

	gzip.4.s: Assembler messages:
	gzip.4.s:2007: Error: value of 326712 too large for field of 2 bytes at 6994
	...

The line 2007 looks like:

	...
	ld 6, block_start at l(6)
	...

Where the symbol block_start is defined at the end of gzip.s as

	...
	.section                .bss,"aw", at nobits
	...
         .lcomm  block_start,8           # 'block_start'
	...

Is there something wrong with my cross-compiler or is the llc-generated code bad?

Thanks, Andi


From baldrick at free.fr  Wed Jun 10 06:11:02 2009
From: baldrick at free.fr (Duncan Sands)
Date: Wed, 10 Jun 2009 15:11:02 +0200
Subject: [LLVMdev] Call to address 0 gets removed
In-Reply-To: <1244637476.5473.4.camel@vostro-1510.invia>
References: <3838f7f10906081648l6397db7v3e369d551b8b54e8@mail.gmail.com>	<A5048CAD-4761-4F76-8FFE-C7DC895F0A2D@apple.com>
	<1244637476.5473.4.camel@vostro-1510.invia>
Message-ID: <4A2FB0E6.7050202@free.fr>

Sylvere Teissier wrote:
>> Calling 0 is undefined behavior; the optimizer is within its rights to  
>> remove this.  Why do you want to call 0?
> 
> For example, on embedded platforms you call 0 to do a soft reset.

You can do this using an asm.  Since you are acting outside the C
standard, this is probably "the right way" of doing it (tm).

Ciao,

Duncan.


From tilmann.scheller at googlemail.com  Wed Jun 10 07:12:34 2009
From: tilmann.scheller at googlemail.com (Tilmann Scheller)
Date: Wed, 10 Jun 2009 16:12:34 +0200
Subject: [LLVMdev] Problem with llc and ppc64
In-Reply-To: <4A2FAF3A.6010407@student.tuwien.ac.at>
References: <4A2FAF3A.6010407@student.tuwien.ac.at>
Message-ID: <aec43a860906100712s2d87fb0fy717ca710d9937a66@mail.gmail.com>

On Wed, Jun 10, 2009 at 3:03 PM, Andreas
Neustifter<e0325716 at student.tuwien.ac.at> wrote:
> Is there something wrong with my cross-compiler or is the llc-generated code bad?
Most likely the latter, the powerpc64-unknown-linux-gnu target is not
officially supported by LLVM. In fact there is no support for the
64-bit PowerPC Linux ABI in the PPC backend at all. The generated
assembly is probably some Darwin-centric 64-bit code.

As part of Google Summer of Code 2009 I'm currently working on making
powerpc-unknown-linux-gnu an officially supported target, it is still
in early stages though.

Greetings,

Tilmann


From e0325716 at student.tuwien.ac.at  Wed Jun 10 07:49:33 2009
From: e0325716 at student.tuwien.ac.at (Andreas Neustifter)
Date: Wed, 10 Jun 2009 16:49:33 +0200
Subject: [LLVMdev] Problem with llc and ppc64
In-Reply-To: <aec43a860906100712s2d87fb0fy717ca710d9937a66@mail.gmail.com>
References: <4A2FAF3A.6010407@student.tuwien.ac.at>
	<aec43a860906100712s2d87fb0fy717ca710d9937a66@mail.gmail.com>
Message-ID: <4A2FC7FD.40401@student.tuwien.ac.at>

Hi,

Tilmann Scheller wrote:

> On Wed, Jun 10, 2009 at 3:03 PM, Andreas
> Neustifter<e0325716 at student.tuwien.ac.at> wrote:
>> Is there something wrong with my cross-compiler or is the llc-generated code bad?
> Most likely the latter, the powerpc64-unknown-linux-gnu target is not
> officially supported by LLVM. In fact there is no support for the
> 64-bit PowerPC Linux ABI in the PPC backend at all. The generated
> assembly is probably some Darwin-centric 64-bit code.
> 
> As part of Google Summer of Code 2009 I'm currently working on making
> powerpc-unknown-linux-gnu an officially supported target, it is still
> in early stages though.

Just to be sure: since you are working on powerpc-unknown-linux-gnu
(which is the triple used for the 32-bit portion of ppc) am I correct in
assuming that the 32 bit part also does not work?

Thanks for the hint, Andi


From tonic at nondot.org  Wed Jun 10 09:19:17 2009
From: tonic at nondot.org (Tanya M. Lattner)
Date: Wed, 10 Jun 2009 09:19:17 -0700 (PDT)
Subject: [LLVMdev] 2009 LLVM Developers' Meeting
Message-ID: <alpine.DEB.2.00.0906100901170.27615@nondot.org>


I just wanted to let everyone know that we do plan to have a LLVM 
Developers' Meeting this year. We are currently planning for it to be held 
in the San Francisco Bay Area in the fall (Sept/Oct). No specific date has 
been selected yet, but an announcement will be made in the next month.

We would not be able to have a free developers meeting without the 
generous contributions of companies and universities. A big thanks to last 
years contributors: Apple, Google, Adobe, and the University of Illinois.

If you or your company is interested in contributing financially to the 
2009 LLVM Developers' Meeting, please send me an email (tonic at nondot.org). 
Any amount is greatly appreciated and will help continue to make this 
meeting free to all attendees.

Thanks,
Tanya Lattner


From simmon12 at cs.uiuc.edu  Wed Jun 10 09:32:49 2009
From: simmon12 at cs.uiuc.edu (Patrick Alexander Simmons)
Date: Wed, 10 Jun 2009 10:32:49 -0600
Subject: [LLVMdev] Pool Allocation and DSA
In-Reply-To: <4A2DEB1F.8080405@uiuc.edu>
References: <4A2D8249.3090604@cs.uiuc.edu> <4A2DEB1F.8080405@uiuc.edu>
Message-ID: <4A2FE031.1050702@cs.uiuc.edu>

Thank you, and I apologize for conflating the two passes.

My main remaining concern is about what happens when there is a node in 
a function's DSGraph that points to a pool (or pools, if there are 
multiple callers) that is not in the DSGraph of that function.  For 
example, on page 3 of the 2005 PLDI paper, the DSGraph given for 
createnode(), Data is pointing to an unlabeled node in the graph.  I 
would like to know specifically what this node is and what would happen 
if getPool() were called on it.  My best guess is that getPool() would 
return NULL.

Moreover, it seems like it should be possible to call a Function with a 
pointer without passing in the pointer's pool, as long as no allocations 
are done using the pointer.  What will the DSNode for that pointer in 
the function's graph look like?  What edges will be coming out of it?

Also, after thinking about it for a while, I don't think it's ever 
possible for a node in the global DSGraph to have pointers to a pool 
that is not also global, thus preventing the problem of a global node 
having pointers into some function's DSGraph.  Am I right?

Thank you again,
--Patrick

John Criswell wrote:
> I don't believe this is correct, or, at the very least, you are using 
> confusing terminology.
>
> First, DSA and Pool Allocation are two completely different things.  DSA 
> is a points-to analysis.  It creates a graph (one per function + 1 
> global graph for global variables) where each node represents a set of 
> memory objects and the edges represent pointers within one memory object 
> that point to another memory object (i.e. if node A points to node B, 
> that means a field in one of the objects in node A points to an object 
> in node B).  The DSGraph also contains a ScalarMap which maps LLVM 
> Values to nodes in the graph (these nodes are called DSNodes).  DSA is 
> somewhat special because it attempts to disambiguate different linked 
> data structures within programs (hence the name Data Structure Analysis, 
> or DSA).
>
> Automatic Pool Allocation (APA) is a transform that is built on top of 
> DSA.  It uses the points-to graphs computed by DSA to group allocations 
> into various pools.  The original idea was to place nodes of the same 
> pointer-based data structure into the same pool to get better cache 
> locality.  The pools that Automatic Pool Allocation creates can either 
> be global variables or local alloca'ed memory, depending upon how long 
> the pool must be alive, what heuristics Automatic Pool Allocation is 
> using, and whether the DSA results are context sensitive or 
> insensitive.  When a pool is created based on context sensitive results, 
> it is stack allocated and passed around as an argument to functions.
>
> However, Automatic Pool Allocation has another use beyond improving 
> performance.  It turns out that if you allocate memory based on the 
> points-to analysis results, you can speed up run-time checks for memory 
> safety.  This leads to SAFECode: a transform built on top of Automatic 
> Pool Allocation that adds additional information to each pool to 
> implement fast run-time checks.
>
> Transforms like SAFECode need to know the mapping between the pointers 
> in a program and the pool in which those pointers were assigned (more 
> accurately, the pool in which the memory objects pointed to by those 
> pointers were allocated).  The easiest way to do this was to have 
> SAFECode query Automatic Pool Allocation.  This is, therefore, the 
> purpose of getPool(): it allows other LLVM passes to ask Automatic Pool 
> Allocation what pool a particular LLVM Value lives in.  The pool is 
> returned as an LLVM Value *.  Depending on whether the pool is global, 
> stack allocated, or passed into the function determines whether it is an 
> LLVM GlobalVariable *, LLVM AllocaInst *, or LLVM Argument *.
>
> -- John T.
>   


From criswell at cs.uiuc.edu  Wed Jun 10 09:41:30 2009
From: criswell at cs.uiuc.edu (John Criswell)
Date: Wed, 10 Jun 2009 11:41:30 -0500
Subject: [LLVMdev] 2009 LLVM Developers' Meeting
In-Reply-To: <alpine.DEB.2.00.0906100901170.27615@nondot.org>
References: <alpine.DEB.2.00.0906100901170.27615@nondot.org>
Message-ID: <4A2FE23A.10704@cs.uiuc.edu>

Tanya M. Lattner wrote:
> I just wanted to let everyone know that we do plan to have a LLVM 
> Developers' Meeting this year. We are currently planning for it to be held 
> in the San Francisco Bay Area in the fall (Sept/Oct). No specific date has 
> been selected yet, but an announcement will be made in the next month.
>   
Just an FYI: qualifying exams in our CS department will be held from
Sept. 21 - Oct. 2 this fall.  I would prefer that the meeting be after
(or at least outside of) the qual period (because I'm taking them this
fall).
:)

-- John T.

> We would not be able to have a free developers meeting without the 
> generous contributions of companies and universities. A big thanks to last 
> years contributors: Apple, Google, Adobe, and the University of Illinois.
>
> If you or your company is interested in contributing financially to the 
> 2009 LLVM Developers' Meeting, please send me an email (tonic at nondot.org). 
> Any amount is greatly appreciated and will help continue to make this 
> meeting free to all attendees.
>
> Thanks,
> Tanya Lattner
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   



From mcheva at cs.mcgill.ca  Wed Jun 10 10:02:49 2009
From: mcheva at cs.mcgill.ca (Nyx)
Date: Wed, 10 Jun 2009 10:02:49 -0700 (PDT)
Subject: [LLVMdev]  Defining/Accessing Structs Dynamically
Message-ID: <23966736.post@talk.nabble.com>


Sorry for the high number of questions I've been posting lately!

I'm currently facing a design problem. I'm making a JIT for a subset of the
MATLAB language and in that language, functions can return many parameters.
The issue is that they will not necessarily return *all* the parameters they
could return. The actual number of returned parameters is defined at
run-time.

For speed, I have been thinking it might be possible to create a struct
containing entries for all the values a function could return, as well as an
integer telling me how many of those values were actually returned (some of
them may not be written to). The issue is that this struct needs to be
defined separately for each function I will JIT compile.

Thus, I need to know how I can define a struct dynamically without having to
write LLVM assembly (is there an API for doing this?), whether or not LLVM
functions can actually return those on the stack, as well as how I can read
and write values to the struct.

Another issue I have is that I need to interface this with C code. Thus, I
will need to be able to know at what address specific values in the struct
lie.

Thank you for your help.

- Max
-- 
View this message in context: http://www.nabble.com/Defining-Accessing-Structs-Dynamically-tp23966736p23966736.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.



From hannibal_08 at mail.com  Wed Jun 10 10:17:04 2009
From: hannibal_08 at mail.com (hannibal hannibal)
Date: Wed, 10 Jun 2009 12:17:04 -0500
Subject: [LLVMdev] CROSS COMPILING LLVM
Message-ID: <20090610171705.9A51E606897@ws1-4.us4.outblaze.com>

 How does one cross compile llvm ? When I attempt to cross compile I get 
:




................................................
...............................................
configure: creating ./config.status
config.status: creating Makefile.common
config.status: executing setup commands
config.status: executing Makefile commands
config.status: executing lib/Makefile commands
config.status: executing lib/sample/Makefile commands
config.status: executing tools/Makefile commands
config.status: executing tools/sample/Makefile commands
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking type of operating system we're going to host on... Linux
checking target architecture... x86
checking for gcc... arm-none-linux-gnueabi-gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... configure: error: cannot run C
compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.


I configured as follows :

AS=arm-none-linux-gnueabi-as
AR=arm-none-linux-gnueabi-ar
CC=arm-none-linux-gnueabi-gcc
CXX=arm-none-linux-gnueabi-g++
LD=arm-none-linux-gnueabi-ld
NM=arm-none-linux-gnueabi-nm
OBJCOPY=arm-none-linux-gnueabi-objcopy
OBJDUMP=arm-none-linux-gnueabi-objdump
RANLIB=arm-none-linux-gnueabi-ranlib
READELF=arm-none-linux-gnueabi-readelf
SIZE=arm-none-linux-gnueabi-size
STRINGS=arm-none-linux-gnueabi-strings
STRIP=arm-none-linux-gnueabi-strips




llvm-2.5/configure \
    --with-llvmgccdir=/home/LLVM-2.5/llvm-gcc4.2-2.5-x86-linux-RHEL4 \
    --enable-optimized \
    --enable-jit \
    --disable-threads \
    --enable-pic \
    --disable-shared \
    --with-pic  \

    --prefix=/home/VIREMENT/src_virement/llvm \

    --build=i686-pc-linux-gnu \
    --host=arm-linux-gnueabi


I am attaching config.log

-- 
Be Yourself @ mail.com!
Choose From 200+ Email Addresses
Get a Free Account at www.mail.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090610/3930a2df/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.log
Type: application/octet-stream
Size: 239622 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090610/3930a2df/attachment.obj>

From schlie at comcast.net  Wed Jun 10 10:35:11 2009
From: schlie at comcast.net (Paul Schlie)
Date: Wed, 10 Jun 2009 13:35:11 -0400
Subject: [LLVMdev]  Call to address 0 gets removed
In-Reply-To: <C6555DF9.165D8%schlie@comcast.net>
Message-ID: <C655670F.165DD%schlie@comcast.net>

> Dale Johannesen wrote:
>> Paul Schlie wrote:
>>> Dale Johannesen wrote:
>>>> Marius Wachtler wrote:
>>>> ...
>>>> The call to address 0 gets removed.
>>>> 
>>>> define i32 @t(i32 %a) noreturn nounwind readnone {
>>>> entry:
>>>>    unreachable
>>>> }
>>>> 
>>>> How can I prevent that the call is removed, without making the
>>>> function addr volatile?
>>>> Does anyone know which optimization removes it?
>>> 
>>> Calling 0 is undefined behavior; the optimizer is within its
>>> rights to remove this.  Why do you want to call 0?
>> 
>> Although a C translation unit may arguably not assign a
>> correspondingly defined function as having a pointer value
>> (address) comparing equal to ((void *) 0);
> 
> Nothing arguable about it, see C99 6.3.2.3

- yes agreed, however:

>> it's not clear that the standard forbids the invocation of such a
>> function
> 
> No such function can exist.  I don't think the standard forbids you
> to call 0, but it makes calling 0 undefined behavior ("behavior, upon
> use of a nonportable or erroneous program construct or of erroneous
> data"), since there can't possibly be a valid function there.

- also yes, however ((void *) 0) need not have a storage representation
  being equivalent to ((int) 0), as for example may be represented as
  being equivalent to ((int) -1) if desired (as may even be desirable
  in some circumstances); in which circumstance striping calls to "0"
  would arguably be wrong to broadly do. Although more practically as:

>> nor does it seem like a good idea to silently strip any such
>> invocations especially if allowed to be specified; as to do so
>> would seemingly only mask potentially legitimate problems, and/or
>> prevent that intended from being performed although potentially
>> relying on an undefined behavior.
>> 
>> (As for example, it's not hard to imagine that it may be desirable
>> to allow a machine which may trap such calls to do, and/or to allow
>> the invocation of some otherwise specified behavior although
>> considered undefined by standard itself.)
> 
> In general, a C compiler is not the right tool to use for
> functionality outside the C language, so I'm not inclined to be
> sympathetic to this line of reasoning.

- I presume you mean things like supporting inline assembly and a
  multitude of other other useful extensions which correspondingly
  have no have no well defined behavior? (a rhetorical question)

I understand you position, just simply don't agree that supporting
extensions which are useful and which do not violate the standard
are worthy of being broadly rejected, unless their specified undefined
behavior may be usefully capitalized upon to justify some more useful
optimization; however as stripping calls to "0", does not seem very
useful to anyone in practice, such calls may be more usefully preserved
possibly in combination with a useful non-portable warning. Merely IMHO.




From tilmann.scheller at googlemail.com  Wed Jun 10 10:53:42 2009
From: tilmann.scheller at googlemail.com (Tilmann Scheller)
Date: Wed, 10 Jun 2009 19:53:42 +0200
Subject: [LLVMdev] Problem with llc and ppc64
In-Reply-To: <4A2FC7FD.40401@student.tuwien.ac.at>
References: <4A2FAF3A.6010407@student.tuwien.ac.at>
	<aec43a860906100712s2d87fb0fy717ca710d9937a66@mail.gmail.com>
	<4A2FC7FD.40401@student.tuwien.ac.at>
Message-ID: <aec43a860906101053t12b5c6b2w796f3b3e3a6d3330@mail.gmail.com>

On Wed, Jun 10, 2009 at 4:49 PM, Andreas
Neustifter<e0325716 at student.tuwien.ac.at> wrote:
> Just to be sure: since you are working on powerpc-unknown-linux-gnu
> (which is the triple used for the 32-bit portion of ppc) am I correct in
> assuming that the 32 bit part also does not work?
Actually a lot of the 32-bit ABI is already implemented (thanks
Nicolas!) and if you're generating the LLVM IR yourself it should
already work reasonably well. I've heard from people successfully
using the JIT on PPC Linux. However, clang and llvm-gcc both lack
proper ABI support, it's also not possible to bootstrap llvm-gcc yet.
I'm currently implementing the missing ABI features in the PPC backend
and I expect to start working on llvm-gcc next week. So stay tuned :)

Greetings,

Tilmann


From jyasskin at google.com  Wed Jun 10 12:17:02 2009
From: jyasskin at google.com (Jeffrey Yasskin)
Date: Wed, 10 Jun 2009 12:17:02 -0700
Subject: [LLVMdev] Why does the x86-64 JIT emit stubs for external calls?
Message-ID: <bb55930e0906101217v57086e51m25829e61c22e6c7d@mail.gmail.com>

In X86CodeGen.cpp, the following code appears in the handler used for
CALL64pcrel32 instructions:

        // Assume undefined functions may be outside the Small codespace.
        bool NeedStub =
          (Is64BitMode &&
              (TM.getCodeModel() == CodeModel::Large ||
               TM.getSubtarget<X86Subtarget>().isTargetDarwin())) ||
          Opcode == X86::TAILJMPd;
        emitGlobalAddress(MO.getGlobal(), X86::reloc_pcrel_word,
                          MO.getOffset(), 0, NeedStub);

This causes every external call to be emitted as a call to a stub
which then jumps to the real function.
I understand, thanks to the helpful folks on #llvm, that calls across
more than 31 bits of address space need to be emitted as a "mov
$ADDRESS, r10; call *r10" pair instead of the simple "call
rip+ADDRESS" used for calls within 31 bits. But why isn't the mov+call
pair emitted inline? And why are Darwin and TAILJMPs special?

Having this out of line seems to lose up to 2% performance on the
Unladen Swallow benchmarks, so, while it's not urgent, it'd be nice to
figure out how to avoid the stubs.

What kind of patch would be welcome to fix this?

Thanks,
Jeffrey


From rjmccall at apple.com  Wed Jun 10 12:25:42 2009
From: rjmccall at apple.com (John McCall)
Date: Wed, 10 Jun 2009 12:25:42 -0700
Subject: [LLVMdev] Call to address 0 gets removed
In-Reply-To: <C655670F.165DD%schlie@comcast.net>
References: <C655670F.165DD%schlie@comcast.net>
Message-ID: <FC8D45B0-7B5E-4349-B177-12092E53543D@apple.com>

There's another point that hasn't been raised yet here, which is that  
the
undefinedness of calling (void*) 0 is a property of C, not necessarily  
of
the LLVM abstract language.  I think you can make an excellent case that
the standard optimizations should not be enforcing C language semantics,
or at least should allow such optimizations to be disabled.

Case in point — calls/loads/stores to null may be undefined behavior  
in C,
but they're certainly not undefined behavior in (say) Java.  There's a  
well-
known implementation trick in JVMs where you optimistically emit code
assuming non-null objects, and then you install signal handlers to raise
exceptions in the cases where you're wrong.  Now, obviously that trick
is going to have implications for the optimizers beyond "don't mark null
stores as unreachable" , but even so, it really shouldn't be totally  
precluded
by widespread assumptions of C semantics.

John.


From nlewycky at google.com  Wed Jun 10 13:11:01 2009
From: nlewycky at google.com (Nick Lewycky)
Date: Wed, 10 Jun 2009 13:11:01 -0700
Subject: [LLVMdev] Call to address 0 gets removed
In-Reply-To: <1244637476.5473.4.camel@vostro-1510.invia>
References: <3838f7f10906081648l6397db7v3e369d551b8b54e8@mail.gmail.com> 
	<A5048CAD-4761-4F76-8FFE-C7DC895F0A2D@apple.com>
	<1244637476.5473.4.camel@vostro-1510.invia>
Message-ID: <fd63e6a40906101311p7c9b6440k75c5f65f84dde63b@mail.gmail.com>

2009/6/10 Sylvere Teissier <st at invia.fr>

> > Calling 0 is undefined behavior; the optimizer is within its rights to
> > remove this.  Why do you want to call 0?
>
> For example, on embedded platforms you call 0 to do a soft reset.


I suggest you create an intrinsic named @llvm.mybackend.reset if that's your
goal. It can then lower to any instruction sequence you want, including call
0.

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090610/7cee1ef2/attachment.html>

From chris.wood77 at hotmail.com  Wed Jun 10 13:08:31 2009
From: chris.wood77 at hotmail.com (Christopher Wood)
Date: Wed, 10 Jun 2009 15:08:31 -0500
Subject: [LLVMdev] Dependency graphs supported by the pass manager
Message-ID: <BLU148-W3067F8C63C0CA8D6F6643291450@phx.gbl>


Hi all:

 

I apologize if this is a stupid question, but I haven't found a direct statement of what kinds of requirements the Pass Manager imposes on pass dependency graphs.  I found a number of bug reports related to unschedulable passes (e.g. "Unable to schedule pass" asserts from the pass manager), but it isn't always clear if these are true bugs in the scheduling algorithm or expected behavior.

 

Specifically, can anyone tell me what the intended behavior of the Pass Manager is in the following scenarios.  In cases I've tested I've included the behavior I've seen--I'm using LLVM 2.4.

 

In all my cases, I'm describing strictly relationships between Function Passes.

 

1) Cycles in the dependency graph (e.g., schedule A when A depends on B; B depends on A)

In tests the Pass Manager overflows the stack and crashes

 

2) A dependency requires rescheduling (e.g. schedule A when A depends on B and C; C depends on B; but C doesn't preserve B)

The Pass Manager should arrive at the sequence B C B A.  Instead I get the "Unable to schedule pass" assertion from PMDataManager::addLowerLevelRequiredPass.

 

2) A pass depends on mutually exclusive graphs (i.e., schedule C when A invalidates B; B invalidates A; C depends on both A and B)

I haven't tried this yet.

 

-- Chris

_________________________________________________________________
Windows Live™ SkyDrive™: Get 25 GB of free online storage.
http://windowslive.com/online/skydrive?ocid=TXT_TAGLM_WL_SD_25GB_062009
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090610/882369f9/attachment.html>

From nlewycky at google.com  Wed Jun 10 13:18:21 2009
From: nlewycky at google.com (Nick Lewycky)
Date: Wed, 10 Jun 2009 13:18:21 -0700
Subject: [LLVMdev] Call to address 0 gets removed
In-Reply-To: <FC8D45B0-7B5E-4349-B177-12092E53543D@apple.com>
References: <C655670F.165DD%schlie@comcast.net>
	<FC8D45B0-7B5E-4349-B177-12092E53543D@apple.com>
Message-ID: <fd63e6a40906101318k64ba8b65oec9b6c1b31e37f39@mail.gmail.com>

2009/6/10 John McCall <rjmccall at apple.com>

> There's another point that hasn't been raised yet here, which is that
> the
> undefinedness of calling (void*) 0 is a property of C, not necessarily
> of
> the LLVM abstract language.  I think you can make an excellent case that
> the standard optimizations should not be enforcing C language semantics,
> or at least should allow such optimizations to be disabled.


All sorts of optimizations rely on this, whether as simple as eliminating
comparisons of alloca against null to knowing that two malloc'd pointers can
never alias (what if malloc returns null? if null is valid then you can
store data there...).

Case in point — calls/loads/stores to null may be undefined behavior
> in C,
> but they're certainly not undefined behavior in (say) Java.  There's a
> well-
> known implementation trick in JVMs where you optimistically emit code
> assuming non-null objects, and then you install signal handlers to raise
> exceptions in the cases where you're wrong.  Now, obviously that trick
> is going to have implications for the optimizers beyond "don't mark null
> stores as unreachable" , but even so, it really shouldn't be totally
> precluded
> by widespread assumptions of C semantics.


The current workaround is to use an alternate address space for your
pointers. At some point we may extend the load/store/call instructions to
specify their exact semantics similarly to the integer overflow proposal (
http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt ).

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090610/7f12b536/attachment.html>

From eli.friedman at gmail.com  Wed Jun 10 13:23:20 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Wed, 10 Jun 2009 13:23:20 -0700
Subject: [LLVMdev] [Patch] Fix SSE2 packing intrinsics return type
In-Reply-To: <000001c9e9ca$99061cb0$cb125610$@net>
References: <000601c9e94d$666af910$3340eb30$@net>
	<f5aa3e9b0906091756x3227fa27i7923d8617788e7df@mail.gmail.com>
	<000001c9e9ca$99061cb0$cb125610$@net>
Message-ID: <f5aa3e9b0906101323y1bc10adfqa012ad71f98d029f@mail.gmail.com>

On Wed, Jun 10, 2009 at 5:54 AM, Nicolas Capens<nicolas at capens.net> wrote:
> What exactly do mean by an AutoUpgrade patch?

See lib/VMCore/AutoUpgrade.cpp.

> I don't see how this could cause any issues with backward compatibility.
> People currently using these intrinsics need a bitcast of the result to
> avoid an assert, and with the patch applied the bitcast is no longer
> necessary.

The issue isn't source-code compatibility (which we don't care about
anyway), but rather bitcode compatibility.

-Eli


From eli.friedman at gmail.com  Wed Jun 10 13:29:59 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Wed, 10 Jun 2009 13:29:59 -0700
Subject: [LLVMdev] Defining/Accessing Structs Dynamically
In-Reply-To: <23966736.post@talk.nabble.com>
References: <23966736.post@talk.nabble.com>
Message-ID: <f5aa3e9b0906101329t5897a96bx711816cd5fef6f37@mail.gmail.com>

On Wed, Jun 10, 2009 at 10:02 AM, Nyx<mcheva at cs.mcgill.ca> wrote:
> Thus, I need to know how I can define a struct dynamically without having to
> write LLVM assembly (is there an API for doing this?), whether or not LLVM
> functions can actually return those on the stack, as well as how I can read
> and write values to the struct.

There's a C++ API for everything you can write in LLVM assembly.  In
this case, I think you want llvm::StructType::get().

> Another issue I have is that I need to interface this with C code. Thus, I
> will need to be able to know at what address specific values in the struct
> lie.

This can get a bit tricky.  If you're using the right TargetData,
simple structures (without any bit-fields, packed members, or other
unusual stuff like that) should just work.  If you're having trouble,
though, you can just force both the C and LLVM structures to be
packed, which should make computing the offsets completely reliable
and straightforward.

-Eli


From eli.friedman at gmail.com  Wed Jun 10 13:32:21 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Wed, 10 Jun 2009 13:32:21 -0700
Subject: [LLVMdev] CROSS COMPILING LLVM
In-Reply-To: <20090610171705.9A51E606897@ws1-4.us4.outblaze.com>
References: <20090610171705.9A51E606897@ws1-4.us4.outblaze.com>
Message-ID: <f5aa3e9b0906101332u44cb01ccrecf0cc15152ecf16@mail.gmail.com>

On Wed, Jun 10, 2009 at 10:17 AM, hannibal hannibal<hannibal_08 at mail.com> wrote:
> checking whether the C compiler works... configure: error: cannot run C
> compiled programs.
> If you meant to cross compile, use `--host'.

DId you try reading this error message?  ("--host" is an option to configure.)

-Eli


From christos700 at yahoo.com  Wed Jun 10 13:45:38 2009
From: christos700 at yahoo.com (christos13)
Date: Wed, 10 Jun 2009 13:45:38 -0700 (PDT)
Subject: [LLVMdev]  problem when compiling to llvm bitcode
Message-ID: <23970657.post@talk.nabble.com>


Hi, I am trying to write a pass to instrument llvm ir, but I got a problem
when I worked with one of the PARSEC benchmarks. 
I stripped the source files as much as i could to still reproduce the error.

When I emit llvm bitcode and then assemble native code I get the following
error:
+ llvm-g++ -emit-llvm annealer_thread.cpp -c -o annealer_thread.o
+ llvm-g++ -emit-llvm rng.cpp -c -o rng.o
+ llc annealer_thread.o -f -o annealer_thread.s
+ llvm-g++ -c annealer_thread.s -o annealer_thread.o
+ llc rng.o -f -o rng.s
+ llvm-g++ -c rng.s -o rng.o
+ llvm-g++ annealer_thread.o rng.o
rng.o: In function `MTRand::reload()':
rng.s:(.text+0x50): multiple definition of `MTRand::reload()'
annealer_thread.o:annealer_thread.s:(.text+0xa0): first defined here
collect2: ld returned 1 exit status

When I don't everything works:
+ llvm-g++ annealer_thread.cpp -c -o annealer_thread.o
+ llvm-g++ rng.cpp -c -o rng.o
+ llvm-g++ rng.o annealer_thread.o

Thanks
Christos

http://www.nabble.com/file/p23970657/annealer_thread.cpp annealer_thread.cpp 
http://www.nabble.com/file/p23970657/rng.h rng.h 
http://www.nabble.com/file/p23970657/rng.cpp rng.cpp 
-- 
View this message in context: http://www.nabble.com/problem-when-compiling-to-llvm-bitcode-tp23970657p23970657.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.



From rjmccall at apple.com  Wed Jun 10 14:25:50 2009
From: rjmccall at apple.com (John McCall)
Date: Wed, 10 Jun 2009 14:25:50 -0700
Subject: [LLVMdev] Call to address 0 gets removed
In-Reply-To: <fd63e6a40906101318k64ba8b65oec9b6c1b31e37f39@mail.gmail.com>
References: <C655670F.165DD%schlie@comcast.net>
	<FC8D45B0-7B5E-4349-B177-12092E53543D@apple.com>
	<fd63e6a40906101318k64ba8b65oec9b6c1b31e37f39@mail.gmail.com>
Message-ID: <4F8342DA-38FC-48F5-A724-1F3F175AAA5E@apple.com>


On Jun 10, 2009, at 1:18 PM, Nick Lewycky wrote:

> 2009/6/10 John McCall <rjmccall at apple.com>
> There's another point that hasn't been raised yet here, which is that
> the
> undefinedness of calling (void*) 0 is a property of C, not necessarily
> of
> the LLVM abstract language.  I think you can make an excellent case  
> that
> the standard optimizations should not be enforcing C language  
> semantics,
> or at least should allow such optimizations to be disabled.
>
> All sorts of optimizations rely on this, whether as simple as  
> eliminating comparisons of alloca against null to knowing that two  
> malloc'd pointers can never alias (what if malloc returns null? if  
> null is valid then you can store data there...).

I'm not saying we should never make *any* assumptions about null, or  
that C-specific assumptions should be totally unwelcome in standard  
passes.  I'm saying that current practice makes it very difficult to  
avoid certain C-specific assumptions.

Let's take your examples.  The assumption that alloca never produces  
null seems like a reasonable cross-language assumption to me, based on  
alloca's status as a compiler-defined (and totally unstandardized)  
intrinsic;  if I need more rigic semantics, I shouldn't be using  
alloca.  The assumption that the function called malloc never returns  
aliasing pointers is indeed a C-specific assumption, but it's one that  
I can easily avoid if necessary by, well, not using C-specific libcall  
optimizations.  And most of these C-inspired assumptions fall into one  
of those two categories:  it's either generally valid or easily  
disabled.

On the other hand, the assumption that calls to null are undefined  
behavior is so hard-coded into instcombine that I can only avoid it by  
refusing to run the entire instcombine pass, or by carefully guarding  
how I emit calls that might be to null.  And I do think this is  
inappropriate for a core pass, just as if someone made  
BasicAliasAnalysis do type-based alias analysis based on C's strict- 
aliasing rules, or if someone modified a loop-counting pass to use C's  
signed-overflow semantics, or so on.  At the very least, there should  
be some way to configure this on the pass.

> Case in point — calls/loads/stores to null may be undefined behavior
> in C,
> but they're certainly not undefined behavior in (say) Java.  There's a
> well-
> known implementation trick in JVMs where you optimistically emit code
> assuming non-null objects, and then you install signal handlers to  
> raise
> exceptions in the cases where you're wrong.  Now, obviously that trick
> is going to have implications for the optimizers beyond "don't mark  
> null
> stores as unreachable" , but even so, it really shouldn't be totally
> precluded
> by widespread assumptions of C semantics.
>
> The current workaround is to use an alternate address space for your  
> pointers. At some point we may extend the load/store/call  
> instructions to specify their exact semantics similarly to the  
> integer overflow proposal ( http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt 
>  ).

I'll note that instcombine actually marks stores to null as  
unreachable regardless of the address space of the pointer, unless I'm  
missing something subtle.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090610/256588b9/attachment.html>

From scottm at aero.org  Wed Jun 10 15:03:46 2009
From: scottm at aero.org (Scott Michel)
Date: Wed, 10 Jun 2009 15:03:46 -0700
Subject: [LLVMdev] obtaining IR for CellBE code
In-Reply-To: <13da638f0905070959g12f6596dp98e70f0b3bdd73dc@mail.gmail.com>
References: <13da638f0905070903m4ed5a966k7206a80e050ba6d9@mail.gmail.com>
	<f5aa3e9b0905070909j4c7fd197m69ecc23ff70192ad@mail.gmail.com>
	<13da638f0905070925u5e2df32r862ffb400d357e87@mail.gmail.com>
	<f5aa3e9b0905070942o125dd7d4v409d47a4a9505dc7@mail.gmail.com>
	<13da638f0905070959g12f6596dp98e70f0b3bdd73dc@mail.gmail.com>
Message-ID: <039E00F6-FEEF-4A46-AC26-AF345AF8E003@aero.org>

Kshitz:

The llvm-gcc frontend will _not_ produce the IR. Specifically, the  
LLVM Cell BE (not "CELLBE") backend needs to capture and expand i32  
multiplies. I'm sure there're other bugs that need to be fixed.

What you want to do, if you really, absolutely want to produce IR is  
use llvm-gcc for PowerPC or x86 to produce the bitcode file. Then, use  
llc to generate the assembly language output for the Cell. But...  
don't use stdio in your code (printf will not work!). There are other  
gotcha's, like using v2i32 vectors (i.e., non-standard vector sizes  
that aren't 128-bits long) and alignment, but so far, it's a strategy  
that's worked to test code locally when I've had a cycle or two to do  
development.


-scooter
  (The Department Director Lives!)

On May 7, 2009, at 9:59 AM, Kshitiz Garg wrote:

> On Thu, May 7, 2009 at 10:12 PM, Eli Friedman  
> <eli.friedman at gmail.com> wrote:
>> On Thu, May 7, 2009 at 9:25 AM, Kshitiz Garg  
>> <ksh.cseiitk at gmail.com> wrote:
>>>> Can you give a couple examples of error messages you're getting?
>>>  llvm-gcc -emit-llvm -S        -W -Wall -Winline -Wno-main  -I.  -I
>>> /opt/cell/sysroot/usr/spu/include -I
>>> /opt/cell/sysroot/opt/cell/sdk/usr/spu/include  -O3 -c  
>>> simpleDMA_spu.c
>>> simpleDMA_spu.c:42:23: error: spu_mfcio.h: No such file or directory
>>
>> Sorry for the extremely low-level question, but did you compile
>> llvm-gcc as a cross-compiler targeting Cell?  Assuming you did, I'm
>> not sure what the issue is; llvm-gcc should be providing that header.
>>
> Oh ok.. I think that is the problem. I was using the llvm-gcc x86 pre
> compiled binary.
> . I will compile llvm-gcc fromt end from the source code and try that.
> Thanks a lot.. :)
> Kshitiz
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



From devang.patel at gmail.com  Wed Jun 10 15:26:50 2009
From: devang.patel at gmail.com (Devang Patel)
Date: Wed, 10 Jun 2009 15:26:50 -0700
Subject: [LLVMdev] Dependency graphs supported by the pass manager
In-Reply-To: <BLU148-W3067F8C63C0CA8D6F6643291450@phx.gbl>
References: <BLU148-W3067F8C63C0CA8D6F6643291450@phx.gbl>
Message-ID: <352a1fb20906101526k4df90f70g6916b4d0f6c09b40@mail.gmail.com>

Hi Christopher,

On Wed, Jun 10, 2009 at 1:08 PM, Christopher
Wood<chris.wood77 at hotmail.com> wrote:
> Hi all:
>
> I apologize if this is a stupid question, but I haven't found a direct
> statement of what kinds of requirements the Pass Manager imposes on pass
> dependency graphs.  I found a number of bug reports related to unschedulable
> passes (e.g. "Unable to schedule pass" asserts from the pass manager), but
> it isn't always clear if these are true bugs in the scheduling algorithm or
> expected behavior.
>
> Specifically, can anyone tell me what the intended behavior of the Pass
> Manager is in the following scenarios.  In cases I've tested I've included
> the behavior I've seen--I'm using LLVM 2.4.
>
> In all my cases, I'm describing strictly relationships between Function
> Passes.
>
> 1) Cycles in the dependency graph (e.g., schedule A when A depends on B; B
> depends on A)
> In tests the Pass Manager overflows the stack and crashes

The pass manager should raise appropriate assertion here.
>
> 2) A dependency requires rescheduling (e.g. schedule A when A depends on B
> and C; C depends on B; but C doesn't preserve B)
> The Pass Manager should arrive at the sequence B C B A.  Instead I get the
> "Unable to schedule pass" assertion from
> PMDataManager::addLowerLevelRequiredPass.

Here, the work around is to required C before B in pass A.

> 2) A pass depends on mutually exclusive graphs (i.e., schedule C when A
> invalidates B; B invalidates A; C depends on both A and B)
> I haven't tried this yet.
>

I think this is similar to case 1)
-
Devang



From scottm at aero.org  Wed Jun 10 15:29:24 2009
From: scottm at aero.org (Scott Michel)
Date: Wed, 10 Jun 2009 15:29:24 -0700
Subject: [LLVMdev] obtaining IR for CellBE code
In-Reply-To: <13da638f0905070959g12f6596dp98e70f0b3bdd73dc@mail.gmail.com>
References: <13da638f0905070903m4ed5a966k7206a80e050ba6d9@mail.gmail.com>
	<f5aa3e9b0905070909j4c7fd197m69ecc23ff70192ad@mail.gmail.com>
	<13da638f0905070925u5e2df32r862ffb400d357e87@mail.gmail.com>
	<f5aa3e9b0905070942o125dd7d4v409d47a4a9505dc7@mail.gmail.com>
	<13da638f0905070959g12f6596dp98e70f0b3bdd73dc@mail.gmail.com>
Message-ID: <1D518EF8-C219-45C8-B20C-82BC5310B206@aero.org>

Kshitz:

The llvm-gcc frontend will _not_ produce the IR. Specifically, the  
LLVM Cell Be (not "CELLBE", or Peter Hofstee might get a tad upset) is  
alpha quality code. It needs 32 bit multiplication, among other things.

You're actually asking for Cell BE-specific IR. However, you can get  
fairly far using llvm-gcc for x86 so long as your code doesn't have  
stdio calls. If you are looking for Cell SDK intrinsics, you're out of  
luck.

Yes, I plan to get back to development at some point this summer, but  
in the meantime, I have a new job that I need to get under control.


-scooter

On May 7, 2009, at 9:59 AM, Kshitiz Garg wrote:

> On Thu, May 7, 2009 at 10:12 PM, Eli Friedman  
> <eli.friedman at gmail.com> wrote:
>> On Thu, May 7, 2009 at 9:25 AM, Kshitiz Garg  
>> <ksh.cseiitk at gmail.com> wrote:
>>>> Can you give a couple examples of error messages you're getting?
>>>  llvm-gcc -emit-llvm -S        -W -Wall -Winline -Wno-main  -I.  -I
>>> /opt/cell/sysroot/usr/spu/include -I
>>> /opt/cell/sysroot/opt/cell/sdk/usr/spu/include  -O3 -c  
>>> simpleDMA_spu.c
>>> simpleDMA_spu.c:42:23: error: spu_mfcio.h: No such file or directory
>>
>> Sorry for the extremely low-level question, but did you compile
>> llvm-gcc as a cross-compiler targeting Cell?  Assuming you did, I'm
>> not sure what the issue is; llvm-gcc should be providing that header.
>>
> Oh ok.. I think that is the problem. I was using the llvm-gcc x86 pre
> compiled binary.
> . I will compile llvm-gcc fromt end from the source code and try that.
> Thanks a lot.. :)
> Kshitiz
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



From eli.friedman at gmail.com  Wed Jun 10 16:28:03 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Wed, 10 Jun 2009 16:28:03 -0700
Subject: [LLVMdev] Call to address 0 gets removed
In-Reply-To: <4F8342DA-38FC-48F5-A724-1F3F175AAA5E@apple.com>
References: <C655670F.165DD%schlie@comcast.net>
	<FC8D45B0-7B5E-4349-B177-12092E53543D@apple.com>
	<fd63e6a40906101318k64ba8b65oec9b6c1b31e37f39@mail.gmail.com>
	<4F8342DA-38FC-48F5-A724-1F3F175AAA5E@apple.com>
Message-ID: <f5aa3e9b0906101628p3f9452aem6d6b000d071a2cc1@mail.gmail.com>

On Wed, Jun 10, 2009 at 2:25 PM, John McCall<rjmccall at apple.com> wrote:
> I'll note that instcombine actually marks stores to null as unreachable
> regardless of the address space of the pointer, unless I'm missing something
> subtle.

That's not intentional; I just filed http://llvm.org/bugs/show_bug.cgi?id=4366 .

-Eli


From clattner at apple.com  Wed Jun 10 22:28:02 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 10 Jun 2009 22:28:02 -0700
Subject: [LLVMdev] Call to address 0 gets removed
In-Reply-To: <FC8D45B0-7B5E-4349-B177-12092E53543D@apple.com>
References: <C655670F.165DD%schlie@comcast.net>
	<FC8D45B0-7B5E-4349-B177-12092E53543D@apple.com>
Message-ID: <43D0848F-DB46-486B-B9E8-FB89E83E45FC@apple.com>


On Jun 10, 2009, at 12:25 PM, John McCall wrote:

> There's another point that hasn't been raised yet here, which is that
> the
> undefinedness of calling (void*) 0 is a property of C, not necessarily
> of
> the LLVM abstract language.  I think you can make an excellent case  
> that
> the standard optimizations should not be enforcing C language  
> semantics,
> or at least should allow such optimizations to be disabled.

For the default address space, LLVM IR *should* currently treat load/ 
store to null as an undefined operation.  To support Java-style  
"potentially trapping" load/store, we need something like this:
http://nondot.org/sabre/LLVMNotes/ExceptionHandlingChanges.txt

-Chris


From baldrick at free.fr  Wed Jun 10 23:08:32 2009
From: baldrick at free.fr (Duncan Sands)
Date: Thu, 11 Jun 2009 08:08:32 +0200
Subject: [LLVMdev] problem when compiling to llvm bitcode
In-Reply-To: <23970657.post@talk.nabble.com>
References: <23970657.post@talk.nabble.com>
Message-ID: <4A309F60.9060905@free.fr>

Hi Christos,

please open a bugreport.

Thanks,

Duncan.

> Hi, I am trying to write a pass to instrument llvm ir, but I got a problem
> when I worked with one of the PARSEC benchmarks. 
> I stripped the source files as much as i could to still reproduce the error.
> 
> When I emit llvm bitcode and then assemble native code I get the following
> error:
> + llvm-g++ -emit-llvm annealer_thread.cpp -c -o annealer_thread.o
> + llvm-g++ -emit-llvm rng.cpp -c -o rng.o
> + llc annealer_thread.o -f -o annealer_thread.s
> + llvm-g++ -c annealer_thread.s -o annealer_thread.o
> + llc rng.o -f -o rng.s
> + llvm-g++ -c rng.s -o rng.o
> + llvm-g++ annealer_thread.o rng.o
> rng.o: In function `MTRand::reload()':
> rng.s:(.text+0x50): multiple definition of `MTRand::reload()'
> annealer_thread.o:annealer_thread.s:(.text+0xa0): first defined here
> collect2: ld returned 1 exit status
> 
> When I don't everything works:
> + llvm-g++ annealer_thread.cpp -c -o annealer_thread.o
> + llvm-g++ rng.cpp -c -o rng.o
> + llvm-g++ rng.o annealer_thread.o
> 
> Thanks
> Christos
> 
> http://www.nabble.com/file/p23970657/annealer_thread.cpp annealer_thread.cpp 
> http://www.nabble.com/file/p23970657/rng.h rng.h 
> http://www.nabble.com/file/p23970657/rng.cpp rng.cpp 



From camille at osculator.net  Thu Jun 11 03:27:07 2009
From: camille at osculator.net (Camille Troillard)
Date: Thu, 11 Jun 2009 12:27:07 +0200
Subject: [LLVMdev] Access a specific address in the JIT compiler
Message-ID: <de35c4ed0906110327u5d5a0654p5a24a1bdf061f547@mail.gmail.com>

Hi,

I am using the JIT compiler to execute code that must interface with
the running process.
I would like to access some specific addresses.

The solution I found is to create a global variable for each address I
want to reference, and pass it as a mapping to the ExecutionEngine
with addGlobalMapping.

Is that how I should do this?
Is there no way to just reference the addresses with constants?


Best,
Cam


From meurant.olivier at gmail.com  Thu Jun 11 04:17:42 2009
From: meurant.olivier at gmail.com (Olivier Meurant)
Date: Thu, 11 Jun 2009 13:17:42 +0200
Subject: [LLVMdev] Access a specific address in the JIT compiler
In-Reply-To: <de35c4ed0906110327u5d5a0654p5a24a1bdf061f547@mail.gmail.com>
References: <de35c4ed0906110327u5d5a0654p5a24a1bdf061f547@mail.gmail.com>
Message-ID: <549cee610906110417n17de2b56je3c07bfc96ca4c46@mail.gmail.com>

This seems to be the "proper" way to do that.

Another possibility, is to create a ConstantInt with the size of the pointer
(found in TargetData), then do a IntToPtr cast, and use this absolute
address in load/store/call.

Cheers,
Olivier.


On Thu, Jun 11, 2009 at 12:27 PM, Camille Troillard
<camille at osculator.net>wrote:

> Hi,
>
> I am using the JIT compiler to execute code that must interface with
> the running process.
> I would like to access some specific addresses.
>
> The solution I found is to create a global variable for each address I
> want to reference, and pass it as a mapping to the ExecutionEngine
> with addGlobalMapping.
>
> Is that how I should do this?
> Is there no way to just reference the addresses with constants?
>
>
> Best,
> Cam
> _______________________________________________
> 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.llvm.org/pipermail/llvm-dev/attachments/20090611/12186791/attachment.html>

From camille at osculator.net  Thu Jun 11 04:23:29 2009
From: camille at osculator.net (Camille Troillard)
Date: Thu, 11 Jun 2009 13:23:29 +0200
Subject: [LLVMdev] Access a specific address in the JIT compiler
In-Reply-To: <549cee610906110417n17de2b56je3c07bfc96ca4c46@mail.gmail.com>
References: <de35c4ed0906110327u5d5a0654p5a24a1bdf061f547@mail.gmail.com>
	<549cee610906110417n17de2b56je3c07bfc96ca4c46@mail.gmail.com>
Message-ID: <de35c4ed0906110423rbedb5bewf2e61381668e2e81@mail.gmail.com>

On Thu, Jun 11, 2009 at 1:17 PM, Olivier
Meurant<meurant.olivier at gmail.com> wrote:
> This seems to be the "proper" way to do that.
>
> Another possibility, is to create a ConstantInt with the size of the pointer
> (found in TargetData), then do a IntToPtr cast, and use this absolute
> address in load/store/call.

Thanks Olivier, this is what I was looking for.


From hannibal_08 at mail.com  Thu Jun 11 06:23:14 2009
From: hannibal_08 at mail.com (hannibal hannibal)
Date: Thu, 11 Jun 2009 08:23:14 -0500
Subject: [LLVMdev]  CROSS COMPILING LLVM
Message-ID: <20090611132314.653D31BF2B6@ws1-10.us4.outblaze.com>

I missed out some lines of the error message. They are:

checking whether the C compiler works... configure: error: cannot
run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
make[1]: Entering directory
`/home/VIREMENT/src_virement/build/BuildTools'
make[1]: *** No targets specified and no makefile found. Stop.
make[1]: Leaving directory `/home/VIREMENT/src_virement/build/BuildTools'
make: *** [cross-compile-build-tools] Error 1


--hannibal

-- 
Be Yourself @ mail.com!
Choose From 200+ Email Addresses
Get a Free Account at www.mail.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090611/d2d8bff0/attachment.html>

From nicolas at capens.net  Thu Jun 11 07:34:43 2009
From: nicolas at capens.net (Nicolas Capens)
Date: Thu, 11 Jun 2009 16:34:43 +0200
Subject: [LLVMdev] Output to a DLL
Message-ID: <000601c9eaa1$c2fec300$48fc4900$@net>

Hi all,

 

I'd like to be able to write JIT-compiled code to a Windows DLL. I have no
idea where to start though. Does LLVM already offer some support for this?
Or would it be straightforward to write my own DLL writer (no advanced
features needed)? Or maybe I could use an external linker? All help highly
appreciated!

 

Cheers,

 

Nicolas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090611/55b4db25/attachment.html>

From ofv at wanadoo.es  Thu Jun 11 08:39:00 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Thu, 11 Jun 2009 17:39:00 +0200
Subject: [LLVMdev] Output to a DLL
References: <000601c9eaa1$c2fec300$48fc4900$@net>
Message-ID: <87bpoueq5n.fsf@telefonica.net>

"Nicolas Capens" <nicolas at capens.net> writes:

Hello Nicolas.

> I'd like to be able to write JIT-compiled code to a Windows DLL. I have no
> idea where to start though. Does LLVM already offer some support for
> this?

Nope. Don't hold your breadth waiting for it. It is far from trivial to
do.

I don't know your requirements, but mine is to avoid compilation every
time the hosting application starts.

I was thinking on:

 1. Compile and spit bitecode from the JIT the first time, load it on
 subsequent sessions. Seems doable. Doesn't work if your goal is
 using code on non-LLVM-aware applications, but if you want to do this
 the JIT is of no use anyways.

 2. Act as a traditional compiler and generate a shared library via
 llvmc + assembler + linker. Tricky, even more so on Windows. Resolving
 symbols is not as easy as is on case 1.

> Or would it be straightforward to write my own DLL writer (no advanced
> features needed)? Or maybe I could use an external linker? All help highly
> appreciated!

If you end hacking a DLL writer, please contribute it to LLVM :-)

-- 
Óscar



From robert at muth.org  Thu Jun 11 08:45:49 2009
From: robert at muth.org (robert muth)
Date: Thu, 11 Jun 2009 11:45:49 -0400
Subject: [LLVMdev] ARM backend failures from (gcc) c torture suite
Message-ID: <8e3491100906110845u4320e017w81080ce7a9f61fff@mail.gmail.com>

I wrote a few scripts to run llvm/arm against the gnu c torture test suite
which consists of  over 900 smallish tests.

There were quite a few failures with llvm/arm which I hereby want to
report (see attached
tarball for the actual failing testsc).

Most of the failures are related to vararg/stdarg.
I think I saw a bug files for this but cannot find it anymore.
Is somebody on this?

Finally, I would like to check in the scripts mentioned above.
What would be a good place for them? "utils/" ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: torture_test_failure.tgz
Type: application/x-gzip
Size: 8049 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090611/abc25931/attachment.bin>

From meurant.olivier at gmail.com  Thu Jun 11 09:10:36 2009
From: meurant.olivier at gmail.com (Olivier Meurant)
Date: Thu, 11 Jun 2009 18:10:36 +0200
Subject: [LLVMdev] Output to a DLL
In-Reply-To: <87bpoueq5n.fsf@telefonica.net>
References: <000601c9eaa1$c2fec300$48fc4900$@net>
	<87bpoueq5n.fsf@telefonica.net>
Message-ID: <549cee610906110910j3afcd6cche85e4ce08d3d990d@mail.gmail.com>

When you say "spit bitecode from the JIT the first time, load it on
subsequent sessions" :
- do you want to write the IR in a file via BitcodeWriter and re-read it via
BitcodeReader ? (you will pay the cost of native code emission on each load
?)
- do you want to write the native code ? In that case, how do you retrieve
the size of the buffer prepared by the "getPointerToFunction" method ? Is it
safe ? I was wondering on how memory access to global variable will come
back in this case ?

Olivier.

On Thu, Jun 11, 2009 at 5:39 PM, Óscar Fuentes <ofv at wanadoo.es> wrote:

> "Nicolas Capens" <nicolas at capens.net> writes:
>
> Hello Nicolas.
>
> > I'd like to be able to write JIT-compiled code to a Windows DLL. I have
> no
> > idea where to start though. Does LLVM already offer some support for
> > this?
>
> Nope. Don't hold your breadth waiting for it. It is far from trivial to
> do.
>
> I don't know your requirements, but mine is to avoid compilation every
> time the hosting application starts.
>
> I was thinking on:
>
>  1. Compile and spit bitecode from the JIT the first time, load it on
>  subsequent sessions. Seems doable. Doesn't work if your goal is
>  using code on non-LLVM-aware applications, but if you want to do this
>  the JIT is of no use anyways.
>
>  2. Act as a traditional compiler and generate a shared library via
>  llvmc + assembler + linker. Tricky, even more so on Windows. Resolving
>  symbols is not as easy as is on case 1.
>
> > Or would it be straightforward to write my own DLL writer (no advanced
> > features needed)? Or maybe I could use an external linker? All help
> highly
> > appreciated!
>
> If you end hacking a DLL writer, please contribute it to LLVM :-)
>
> --
> Óscar
>
> _______________________________________________
> 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.llvm.org/pipermail/llvm-dev/attachments/20090611/1b98d8ec/attachment.html>

From criswell at cs.uiuc.edu  Thu Jun 11 09:14:08 2009
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu, 11 Jun 2009 11:14:08 -0500
Subject: [LLVMdev] Pool Allocation and DSA
In-Reply-To: <4A2FE031.1050702@cs.uiuc.edu>
References: <4A2D8249.3090604@cs.uiuc.edu> <4A2DEB1F.8080405@uiuc.edu>
	<4A2FE031.1050702@cs.uiuc.edu>
Message-ID: <4A312D50.7040501@cs.uiuc.edu>

Patrick Alexander Simmons wrote:
> Thank you, and I apologize for conflating the two passes.
>
> My main remaining concern is about what happens when there is a node in 
> a function's DSGraph that points to a pool (or pools, if there are 
> multiple callers) that is not in the DSGraph of that function.  For 
> example, on page 3 of the 2005 PLDI paper, the DSGraph given for 
> createnode(), Data is pointing to an unlabeled node in the graph.  I 
> would like to know specifically what this node is and what would happen 
> if getPool() were called on it.  My best guess is that getPool() would 
> return NULL.
>   
Ah.  I think I see the issue now.  There may be some instances in which
pool allocation may not need to pass a pointer's pool into a function
because there are no allocations or deallocations from that pool.  In
that case, what does getPool() return?

I have no idea.  We added the getPool() method to support SAFECode , and
SAFECode requires that the pool for a pointer always be available, so
the above situation cannot (or at least, should not) occur.  I didn't
think of the above case when adding getPool() because it's not supposed
to happen for SAFECode, so what it does is anybody's guess.

If your use of pool allocation requires that you can always get the pool
handle for a pointer, you need to make sure that pool allocation is
configured so that it doesn't generate the above scenario.  I think
there is an option to make all pools be global pools.
 
> Moreover, it seems like it should be possible to call a Function with a 
> pointer without passing in the pointer's pool, as long as no allocations 
> are done using the pointer.  What will the DSNode for that pointer in 
> the function's graph look like?  What edges will be coming out of it?
>   
In the DSGraph for the function, you should have a DSNode for the
pointer that is passed into the function as a parameter.  Whether there
is an explicit pool for it is another matter, but there will be a DSNode
for the pointer.

> Also, after thinking about it for a while, I don't think it's ever 
> possible for a node in the global DSGraph to have pointers to a pool 
> that is not also global, thus preventing the problem of a global node 
> having pointers into some function's DSGraph.  Am I right?
>   
I don't know.  Global variables can point to stack and heap objects, so
DSA must have a way to represent this in the DSGraphs.  However, if you
configure pool allocation to allow for context sensitivity (i.e., it can
allocate pool descriptors on the stack), then I don't know if it will
place stack/heap objects pointed to by global variables in a global pool
or in a stack-allocated pool.

-- John T.

> Thank you again,
> --Patrick
>
> John Criswell wrote:
>   
>> I don't believe this is correct, or, at the very least, you are using 
>> confusing terminology.
>>
>> First, DSA and Pool Allocation are two completely different things.  DSA 
>> is a points-to analysis.  It creates a graph (one per function + 1 
>> global graph for global variables) where each node represents a set of 
>> memory objects and the edges represent pointers within one memory object 
>> that point to another memory object (i.e. if node A points to node B, 
>> that means a field in one of the objects in node A points to an object 
>> in node B).  The DSGraph also contains a ScalarMap which maps LLVM 
>> Values to nodes in the graph (these nodes are called DSNodes).  DSA is 
>> somewhat special because it attempts to disambiguate different linked 
>> data structures within programs (hence the name Data Structure Analysis, 
>> or DSA).
>>
>> Automatic Pool Allocation (APA) is a transform that is built on top of 
>> DSA.  It uses the points-to graphs computed by DSA to group allocations 
>> into various pools.  The original idea was to place nodes of the same 
>> pointer-based data structure into the same pool to get better cache 
>> locality.  The pools that Automatic Pool Allocation creates can either 
>> be global variables or local alloca'ed memory, depending upon how long 
>> the pool must be alive, what heuristics Automatic Pool Allocation is 
>> using, and whether the DSA results are context sensitive or 
>> insensitive.  When a pool is created based on context sensitive results, 
>> it is stack allocated and passed around as an argument to functions.
>>
>> However, Automatic Pool Allocation has another use beyond improving 
>> performance.  It turns out that if you allocate memory based on the 
>> points-to analysis results, you can speed up run-time checks for memory 
>> safety.  This leads to SAFECode: a transform built on top of Automatic 
>> Pool Allocation that adds additional information to each pool to 
>> implement fast run-time checks.
>>
>> Transforms like SAFECode need to know the mapping between the pointers 
>> in a program and the pool in which those pointers were assigned (more 
>> accurately, the pool in which the memory objects pointed to by those 
>> pointers were allocated).  The easiest way to do this was to have 
>> SAFECode query Automatic Pool Allocation.  This is, therefore, the 
>> purpose of getPool(): it allows other LLVM passes to ask Automatic Pool 
>> Allocation what pool a particular LLVM Value lives in.  The pool is 
>> returned as an LLVM Value *.  Depending on whether the pool is global, 
>> stack allocated, or passed into the function determines whether it is an 
>> LLVM GlobalVariable *, LLVM AllocaInst *, or LLVM Argument *.
>>
>> -- John T.
>>   
>>     
> _______________________________________________
> 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  Thu Jun 11 09:27:22 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Thu, 11 Jun 2009 18:27:22 +0200
Subject: [LLVMdev] Output to a DLL
References: <000601c9eaa1$c2fec300$48fc4900$@net>
	<87bpoueq5n.fsf@telefonica.net>
	<549cee610906110910j3afcd6cche85e4ce08d3d990d@mail.gmail.com>
Message-ID: <877hzienx1.fsf@telefonica.net>

Olivier Meurant <meurant.olivier at gmail.com> writes:

> When you say "spit bitecode from the JIT the first time, load it on
> subsequent sessions" :
> - do you want to write the IR in a file via BitcodeWriter and re-read it via
> BitcodeReader ? (you will pay the cost of native code emission on each load
> ?)

Yes. It is a small cost compared with compiling all the way from the
source code.

> - do you want to write the native code ? In that case, how do you retrieve
> the size of the buffer prepared by the "getPointerToFunction" method ? Is it
> safe ? I was wondering on how memory access to global variable will come
> back in this case ?

I don't want to write and read native code because it is not relocatable.

-- 
Óscar



From clattner at apple.com  Thu Jun 11 10:28:45 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 11 Jun 2009 10:28:45 -0700
Subject: [LLVMdev] Regular Expressions
In-Reply-To: <200906091439.18446.dag@cray.com>
References: <200906081700.n58H0Zvi022899@zion.cs.uiuc.edu>
	<200906091400.25004.dag@cray.com>
	<FC9FD7DE-415E-4273-A4C0-B03724119620@apple.com>
	<200906091439.18446.dag@cray.com>
Message-ID: <21EF7717-A7BE-44EE-B320-53A6BEEAE8EF@apple.com>


On Jun 9, 2009, at 12:39 PM, David Greene wrote:

> On Tuesday 09 June 2009 14:34, Dan Gohman wrote:
>> Can you describe what problem you're trying to solve here?  Does it
>> really need Regular Expressions?
>
> Yes.  I want TableGen to be able to infer lots of stuff  
> programmatically.
> This helps tremendously when specifying things like, oh, AVX.  :)

I don't see how this relates to regex's, and really don't want to suck  
in an external regex library.  Can you give an example of how this  
would help?

> BTW, is there a process for dropping compiler support?  Eventually  
> most
> compilers will have TR1 except for very old versions.  It's not  
> feasible
> to support all of those crufty compilers forever.


There is no formal process.  What do you need out of TR1?  Is it  
possible to make it conditional?  Many old compilers are already  
broken anyway, but all it takes is one "popular" one to make it a no-go.

-Chris


From samuraileumas at yahoo.com  Thu Jun 11 11:06:46 2009
From: samuraileumas at yahoo.com (Samuel Crow)
Date: Thu, 11 Jun 2009 11:06:46 -0700 (PDT)
Subject: [LLVMdev] PEG parsers? (was Re: Regular Expressions)
In-Reply-To: <21EF7717-A7BE-44EE-B320-53A6BEEAE8EF@apple.com>
References: <200906081700.n58H0Zvi022899@zion.cs.uiuc.edu>
	<200906091400.25004.dag@cray.com>
	<FC9FD7DE-415E-4273-A4C0-B03724119620@apple.com>
	<200906091439.18446.dag@cray.com>
	<21EF7717-A7BE-44EE-B320-53A6BEEAE8EF@apple.com>
Message-ID: <41039.45829.qm@web62008.mail.re1.yahoo.com>


Hello everybody,

I don't quite understand how the proposed regex library works but I know that PEG parser generators use a super-set of regex functionality to define their parsers.  There's also a nice one on Google code called YARDparser that uses templates based on PEGs to generate efficient recursive-decent parsers.

Furthermore, my partner and I am working on an interpreter for PEG syntax based parsers and LLVM Assembly code for all of the code-generation stages so that we can debug the code and the parser all in one go.  It's part of the Mattathias BASIC project on SourceForge.net and don't let the LGPL license scare you.  We can change the license for the parser generator.  It's only the extensible BASIC compiler and interpreter we are building with it that is required to be LGPL due to the runtime libraries.

Does the prospect of a PEG based syntax interest the team for the TableGen?  They are wonderfully simple to maintain since they don't allow ambiguity of any type.  Their downfall is that since they use a greedy algorithm they sometimes degrade performance to O(n) where a nongreedy algorithm would result in O(1).  Since the YARDparser is template-based, it should be possible to slip a stringmap into the keyword lookup to bring the performance back up to a more resonable specification.

Let me know what you think.

--Sam Crow



----- Original Message ----
> From: Chris Lattner <clattner at apple.com>
> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Sent: Thursday, June 11, 2009 12:28:45 PM
> Subject: Re: [LLVMdev] Regular Expressions
> 
> 
> On Jun 9, 2009, at 12:39 PM, David Greene wrote:
> 
> > On Tuesday 09 June 2009 14:34, Dan Gohman wrote:
> >> Can you describe what problem you're trying to solve here?  Does it
> >> really need Regular Expressions?
> >
> > Yes.  I want TableGen to be able to infer lots of stuff  
> > programmatically.
> > This helps tremendously when specifying things like, oh, AVX.  :)
> 
> I don't see how this relates to regex's, and really don't want to suck  
> in an external regex library.  Can you give an example of how this  
> would help?
> 
> > BTW, is there a process for dropping compiler support?  Eventually  
> > most
> > compilers will have TR1 except for very old versions.  It's not  
> > feasible
> > to support all of those crufty compilers forever.
> 
> 
> There is no formal process.  What do you need out of TR1?  Is it  
> possible to make it conditional?  Many old compilers are already  
> broken anyway, but all it takes is one "popular" one to make it a no-go.
> 
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



      


From e0325716 at student.tuwien.ac.at  Thu Jun 11 11:09:40 2009
From: e0325716 at student.tuwien.ac.at (Andreas Neustifter)
Date: Thu, 11 Jun 2009 20:09:40 +0200
Subject: [LLVMdev] CROSS COMPILING LLVM
In-Reply-To: <20090610171705.9A51E606897@ws1-4.us4.outblaze.com>
References: <20090610171705.9A51E606897@ws1-4.us4.outblaze.com>
Message-ID: <4A314864.5050701@student.tuwien.ac.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I stumbled over this one too, recently.

hannibal hannibal wrote:
> ................................................
> ...............................................
> configure: creating ./config.status
> config.status: creating Makefile.common
> config.status: executing setup commands
> config.status: executing Makefile commands
> config.status: executing lib/Makefile commands
> config.status: executing lib/sample/Makefile commands
> config.status: executing tools/Makefile commands
> config.status: executing tools/sample/Makefile commands

AFIAK what is following is the configure in the BuildTools folder where
tablegen ant the like are built.
> checking build system type... i686-pc-linux-gnu
> checking host system type... i686-pc-linux-gnu
> checking target system type... i686-pc-linux-gnu
> checking type of operating system we're going to host on... Linux
> checking target architecture... x86
> checking for gcc... arm-none-linux-gnueabi-gcc
As you see the only compiler it finds is the arm-cross-compiler, but not
the i686-pc-linux-gnu-compiler to build tablegen natively for the build
environment.

Its no use of setting the CC environment variable to the arm-compiler
since the whole build is using it. You have to have both (the system
compiler for i686-pc-linux-gnu and the cross compiler for
arm-none-linux-gnueabi on your path.

At the configure (with --host=ppc64-linux in this case) you get:

> configure: WARNING: If you wanted to set the --build type, don't use --host.
>     If a cross compiler is detected then cross compile mode will be used.
> checking build system type... x86_64-unknown-linux-gnu
> checking host system type... powerpc64-unknown-linux-gnu
> checking target system type... powerpc64-unknown-linux-gnu
Thats the proper systems.

> checking type of operating system we're going to host on... Linux
> checking target architecture... PowerPC
> checking for ppc64-linux-gcc... ppc64-linux-gcc
So (in this case) the cross-compiler has to be named ppc64-linux-gcc

>........
> checking for gcc... gcc
And then its also checking for the native compiler to build the BuildTools.

So: puth both compilers (the native one and the cross-compiler) onto the
path and name the cross-compiler so configure finds it.

Andi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoxR+sACgkQPiYq0rq7s/AjQACfUPt+aRozBLt7FAYgx54BCiYC
h6UAnRyOtOivOancU6UucqXnC/CuZpls
=AwkH
-----END PGP SIGNATURE-----


From evan.cheng at apple.com  Thu Jun 11 11:27:12 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Thu, 11 Jun 2009 11:27:12 -0700
Subject: [LLVMdev] patch for llc/ARM: added mechanism to move
	switch	tables from .text -> .data; also cleanup and documentation
In-Reply-To: <8e3491100906081442l3417b3e9nf3abeda39f8f2514@mail.gmail.com>
References: <8e3491100906021826p4530f341xbb168d260c21342e@mail.gmail.com>
	<0453D1AB-FA5D-4947-BE50-02223AB8955B@apple.com>
	<8e3491100906070659k481580afk2d562a6c4a21a2a4@mail.gmail.com>
	<C2EC9000-8447-42CB-B3CD-5DB1652C356F@apple.com>
	<8e3491100906081442l3417b3e9nf3abeda39f8f2514@mail.gmail.com>
Message-ID: <A81A63F1-DB89-45FD-A5DB-32E09A8C69EB@apple.com>


On Jun 8, 2009, at 2:42 PM, robert muth wrote:

> On Sun, Jun 7, 2009 at 11:53 PM, Evan Cheng <evan.cheng at apple.com>  
> wrote:
>>
>> On Jun 7, 2009, at 6:59 AM, robert muth wrote:
>>
>>> On Sat, Jun 6, 2009 at 4:51 PM, Evan Cheng<evan.cheng at apple.com>
>>> wrote:
>>>> +cl::opt<std::string> FlagJumpTableSection("jumptable-section",
>>>> +                                            
>>>> cl::init(".data.jtab"));
>>>> +
>>>
>>> I thought it would be nice to group all the jumptables together.
>>> But as long as it stays configurable, I am fine to change the  
>>> default
>>> to ".data".
>>
>> There is already a TargetAsmInfo::JumpTableDataSection. Why not just
>> use that?
>
> Nice find. I will use that and possible change the current setting,
> ".const", if it does not work,
>
>>>
>>>> Is this necessary? Why not just put it in the normal data section?
>>>> Also "outline" jumptable seems like a strange term. Can you think  
>>>> of
>>>> something else?
>>>
>>>
>>> Yes, that is a tough one. How about "NonInline" instead.
>>
>> Or "OutOfLine"?
>
> That works for me.
>
>> Please add a test case as well. Thanks,
>
> I am not sure how to go about testing.

For this please just add a test case to the llvm dejagnu tests.

thanks,

Evan

>
> I have  a script that compiles a bunch of test
> programs (gnu c torture test, etc.) and then runs the executables
> on qemu.  I run this script with and without my flags and
> make sure that I do not introduce any new problems
> -- there are currently plenty of vararg issues.
>
> I was thinking of sending this script to the list
> or maybe checking it into the llvm tree.
>
> The key is that whatever tests there are they should just
> be run with and without the new flag.
> How do you run backend tests?
>
> Robert
>
>
>
>
>> Evan
>>
>>>
>>> Robert
>>>
>>>> Thanks,
>>>> Evan
>>>>
>>>> Sent from my iPhone
>>>> On Jun 2, 2009, at 6:26 PM, robert muth <robert at muth.org> wrote:
>>>>
>>>> Hi:
>>>>
>>>> This is my first patch submission. Hopefully, this is the proper  
>>>> the
>>>> protocol.
>>>> Attached is a patch for the llc ARM backend:
>>>>
>>>> Added mechanism to generate switch table in a data section
>>>> rather than having it interleaved with the code.
>>>> This is controlled by command line flags and off by default.
>>>> Also, tried to document and improve the code where I modified it.
>>>>
>>>> Robert
>>>>
>>>> <llc.patch.txt>
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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
>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



From eli.friedman at gmail.com  Thu Jun 11 12:11:13 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Thu, 11 Jun 2009 12:11:13 -0700
Subject: [LLVMdev] Output to a DLL
In-Reply-To: <000601c9eaa1$c2fec300$48fc4900$@net>
References: <000601c9eaa1$c2fec300$48fc4900$@net>
Message-ID: <f5aa3e9b0906111211p5aaf2fb6sebdd7585bd20cb9@mail.gmail.com>

On Thu, Jun 11, 2009 at 7:34 AM, Nicolas Capens<nicolas at capens.net> wrote:
> I’d like to be able to write JIT-compiled code to a Windows DLL. I have no
> idea where to start though. Does LLVM already offer some support for this?

You can't use the JIT to compile code for a DLL; it simply isn't
designed for that.

> Or would it be straightforward to write my own DLL writer (no advanced
> features needed)? Or maybe I could use an external linker? All help highly
> appreciated!

You can write out an assembly (.s) file and use mingw as+ld to build a
DLL.  Essentially, this is just building a DLL the same way a
conventional compiler like llvm-gcc would.

Directly emitting a DLL would be a lot of work, although it doesn't
require any architectural changes to LLVM; you'd need something like
http://wiki.llvm.org/Direct_Object_Code_Emission plus some code to
handle linking.

-Eli



From evan.cheng at apple.com  Thu Jun 11 12:54:57 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Thu, 11 Jun 2009 12:54:57 -0700
Subject: [LLVMdev] Why does the x86-64 JIT emit stubs for external calls?
In-Reply-To: <bb55930e0906101217v57086e51m25829e61c22e6c7d@mail.gmail.com>
References: <bb55930e0906101217v57086e51m25829e61c22e6c7d@mail.gmail.com>
Message-ID: <35A0A609-B73D-441E-88B8-E7B7B0922B81@apple.com>


On Jun 10, 2009, at 12:17 PM, Jeffrey Yasskin wrote:

> In X86CodeGen.cpp, the following code appears in the handler used for
> CALL64pcrel32 instructions:
>
>        // Assume undefined functions may be outside the Small  
> codespace.
>        bool NeedStub =
>          (Is64BitMode &&
>              (TM.getCodeModel() == CodeModel::Large ||
>               TM.getSubtarget<X86Subtarget>().isTargetDarwin())) ||
>          Opcode == X86::TAILJMPd;
>        emitGlobalAddress(MO.getGlobal(), X86::reloc_pcrel_word,
>                          MO.getOffset(), 0, NeedStub);
>
> This causes every external call to be emitted as a call to a stub
> which then jumps to the real function.
> I understand, thanks to the helpful folks on #llvm, that calls across
> more than 31 bits of address space need to be emitted as a "mov
> $ADDRESS, r10; call *r10" pair instead of the simple "call
> rip+ADDRESS" used for calls within 31 bits. But why isn't the mov+call
> pair emitted inline? And why are Darwin and TAILJMPs special?

This is needed because of lazy compilation, before the callee is  
resolved, it is just a JIT stub. It's heap allocated so it may not be  
in the lower 4G even if the code size model is small. I know this is  
the case on Darwin x86_64, I am not sure about other targets. I forgot  
why this is needed for tail calls, sorry.

In theory we can make the code generator inline mov+call, the reality  
is it doesn't know whether it's jitting or not. Also, we really want  
to keep the code generation the same (as much as possible) whether  
it's jitting or compiling. One possible solution for this is to add  
code size model specifically for JIT so code generator can generate  
more efficient code in that configuration.

Evan

>
>
> Having this out of line seems to lose up to 2% performance on the
> Unladen Swallow benchmarks, so, while it's not urgent, it'd be nice to
> figure out how to avoid the stubs.
>
> What kind of patch would be welcome to fix this?
>
> Thanks,
> Jeffrey
> _______________________________________________
> 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  Thu Jun 11 13:07:20 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Thu, 11 Jun 2009 22:07:20 +0200
Subject: [LLVMdev] CROSS COMPILING LLVM
References: <20090610171705.9A51E606897@ws1-4.us4.outblaze.com>
Message-ID: <873aa6edqf.fsf@telefonica.net>

You can try cross-compiling with cmake if the traditional approach
doesn't work for you. Yesterday I tried mingw on Linux and it worked
fine (apart from a bug related to mingw's binutils that appears late on
the build process).

http://www.llvm.org/docs/CMake.html

-- 
Óscar



From kevinn.tian at gmail.com  Thu Jun 11 13:45:55 2009
From: kevinn.tian at gmail.com (Kelvin Tian)
Date: Thu, 11 Jun 2009 16:45:55 -0400
Subject: [LLVMdev] Code related to "Run Time Optimization" and "Offline
	Reoptimizer"
Message-ID: <9846fcd40906111345q2705726cy6724db30baadb5d7@mail.gmail.com>

Hi,

    Sorry for this silly question, but I couldn't find the source codes
related to "Run Time Optimization" and "Offline Reoptimizer". As there's few
references talking about those two parts except for Chris's master thesis.
There's a "Runtime" souce code folder, but the codes under that folder
mainly relate to gathering profiling information or runtime gc. Can anybody
help me point out those two parts of codes in the source code folder? Thanks
a lot!


--
Best regards,
Kelvin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090611/985d0768/attachment.html>

From dag at cray.com  Thu Jun 11 14:01:56 2009
From: dag at cray.com (David Greene)
Date: Thu, 11 Jun 2009 16:01:56 -0500
Subject: [LLVMdev] Regular Expressions
In-Reply-To: <21EF7717-A7BE-44EE-B320-53A6BEEAE8EF@apple.com>
References: <200906081700.n58H0Zvi022899@zion.cs.uiuc.edu>
	<200906091439.18446.dag@cray.com>
	<21EF7717-A7BE-44EE-B320-53A6BEEAE8EF@apple.com>
Message-ID: <200906111601.57203.dag@cray.com>

On Thursday 11 June 2009 12:28, Chris Lattner wrote:
> On Jun 9, 2009, at 12:39 PM, David Greene wrote:
> > On Tuesday 09 June 2009 14:34, Dan Gohman wrote:
> >> Can you describe what problem you're trying to solve here?  Does it
> >> really need Regular Expressions?
> >
> > Yes.  I want TableGen to be able to infer lots of stuff
> > programmatically.
> > This helps tremendously when specifying things like, oh, AVX.  :)
>
> I don't see how this relates to regex's, and really don't want to suck
> in an external regex library.  Can you give an example of how this
> would help?

Sure:

[Top-level specification]
defm CVTSI2SS : sse1_avx_fp_cvt_scalar_xs_scalar64_xs_node_sintrinsic_rm<
  0x2D, "cvtsi2ss", sint_to_fp, "cvtsi2ss", "f32", "i32">;

[Meanwhile, down in the guts...]

class fp_cvt_scalar_VXSnrr<  
// Parent: avx_fp_cvt_scalar_xs_node_rm_DEF_V#NAME#_128rr
  bits<8> opc,
  string OpcodeStr,
  SDNode OpNode,
  string DstType,
  string SrcType,
  int CustomPatterns = 0,
  list<dag> patterns = [],
  string asm = ""
>: fp_unary_vxs_n_rm_rr<
    opc,
    !cast<RegisterClass>(!patsubst("^f([0-9]+)","FR$1",!patsubst("^i([0-9]+)","GR$1",DstType))),
[...]

Basically, the code keys off type strings to deduce register classes and 
other such things.  This makes specifying things like converts much easier 
because one doesn't need to pass a bunch of additional parameters around to 
specify register classes, etc. when it is entirely obvious what they should be 
given other parameters.

I'm trying to reduce the number of classes/parameters to deal with so I
can eventually get rid of the Perl script that's generating most of this
stuff right now.  This kind of pattern matching and substitution really
helps simplify things to a point where I can imagine manually maintaining
a smaller amount of information.

The BSD regex library is very tiny, almost ideal for what we want to do, which
is fill a functionality hole on Windows only.

                                     -Dave


From nicolas at capens.net  Thu Jun 11 14:03:40 2009
From: nicolas at capens.net (Nicolas Capens)
Date: Thu, 11 Jun 2009 23:03:40 +0200
Subject: [LLVMdev] Output to a DLL
In-Reply-To: <87bpoueq5n.fsf@telefonica.net>
References: <000601c9eaa1$c2fec300$48fc4900$@net>
	<87bpoueq5n.fsf@telefonica.net>
Message-ID: <001e01c9ead8$18a2fca0$49e8f5e0$@net>

Hi Óscar,

For me writing a DLL would have two purposes: one is to reduce compilation
time (i.e. make it work like a cache), but a second very important goal is
to be able to profile code at the assembly level (using AMD's CodeAnalyst
for example).

Fortunately, the code I'm generating consists of only pure functions. So
there's no need for linking symbols.

Anyway, thanks for the ideas. I'll definitely investigate generating
assembly output and using an external compiler and linker for it.

Cheers,

Nicolas


-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Óscar Fuentes
Sent: donderdag 11 juni 2009 17:39
To: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] Output to a DLL

"Nicolas Capens" <nicolas at capens.net> writes:

Hello Nicolas.

> I'd like to be able to write JIT-compiled code to a Windows DLL. I have no
> idea where to start though. Does LLVM already offer some support for
> this?

Nope. Don't hold your breadth waiting for it. It is far from trivial to
do.

I don't know your requirements, but mine is to avoid compilation every
time the hosting application starts.

I was thinking on:

 1. Compile and spit bitecode from the JIT the first time, load it on
 subsequent sessions. Seems doable. Doesn't work if your goal is
 using code on non-LLVM-aware applications, but if you want to do this
 the JIT is of no use anyways.

 2. Act as a traditional compiler and generate a shared library via
 llvmc + assembler + linker. Tricky, even more so on Windows. Resolving
 symbols is not as easy as is on case 1.

> Or would it be straightforward to write my own DLL writer (no advanced
> features needed)? Or maybe I could use an external linker? All help highly
> appreciated!

If you end hacking a DLL writer, please contribute it to LLVM :-)

-- 
Óscar

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




From dag at cray.com  Thu Jun 11 14:05:15 2009
From: dag at cray.com (David Greene)
Date: Thu, 11 Jun 2009 16:05:15 -0500
Subject: [LLVMdev] PEG parsers? (was Re: Regular Expressions)
In-Reply-To: <41039.45829.qm@web62008.mail.re1.yahoo.com>
References: <200906081700.n58H0Zvi022899@zion.cs.uiuc.edu>
	<21EF7717-A7BE-44EE-B320-53A6BEEAE8EF@apple.com>
	<41039.45829.qm@web62008.mail.re1.yahoo.com>
Message-ID: <200906111605.15398.dag@cray.com>

On Thursday 11 June 2009 13:06, Samuel Crow wrote:
> Hello everybody,
>
> I don't quite understand how the proposed regex library works but I know
> that PEG parser generators use a super-set of regex functionality to define
> their parsers.  There's also a nice one on Google code called YARDparser
> that uses templates based on PEGs to generate efficient recursive-decent
> parsers.

> Does the prospect of a PEG based syntax interest the team for the TableGen?

Right now we don't need anything as stong as a full parser for string pattern
matching and substitution in TableGen.  Anything we add should be small.  The
BSD regex library is about the smallest I've seen.  Nine source files totaling 
3,300 lines.

                               -Dave


From nicolas at capens.net  Thu Jun 11 14:10:02 2009
From: nicolas at capens.net (Nicolas Capens)
Date: Thu, 11 Jun 2009 23:10:02 +0200
Subject: [LLVMdev] Output to a DLL
In-Reply-To: <f5aa3e9b0906111211p5aaf2fb6sebdd7585bd20cb9@mail.gmail.com>
References: <000601c9eaa1$c2fec300$48fc4900$@net>
	<f5aa3e9b0906111211p5aaf2fb6sebdd7585bd20cb9@mail.gmail.com>
Message-ID: <001f01c9ead8$fcaf6b40$f60e41c0$@net>

Hi Eli,

Thanks a lot for the advise. The existing direct object code emission looks
very interesting and I might give it a try to create a basic DLL writer.

Generating an assembly file and compiling it to a DLL 'externally' sounds
like the most straightforward way for now so I'll try that first...

Cheers,

Nicolas


-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Eli Friedman
Sent: donderdag 11 juni 2009 21:11
To: LLVM Developers Mailing List
Subject: Re: [LLVMdev] Output to a DLL

On Thu, Jun 11, 2009 at 7:34 AM, Nicolas Capens<nicolas at capens.net> wrote:
> I'd like to be able to write JIT-compiled code to a Windows DLL. I have no
> idea where to start though. Does LLVM already offer some support for this?

You can't use the JIT to compile code for a DLL; it simply isn't
designed for that.

> Or would it be straightforward to write my own DLL writer (no advanced
> features needed)? Or maybe I could use an external linker? All help highly
> appreciated!

You can write out an assembly (.s) file and use mingw as+ld to build a
DLL.  Essentially, this is just building a DLL the same way a
conventional compiler like llvm-gcc would.

Directly emitting a DLL would be a lot of work, although it doesn't
require any architectural changes to LLVM; you'd need something like
http://wiki.llvm.org/Direct_Object_Code_Emission plus some code to
handle linking.

-Eli

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



From jyasskin at google.com  Thu Jun 11 16:24:50 2009
From: jyasskin at google.com (Jeffrey Yasskin)
Date: Thu, 11 Jun 2009 16:24:50 -0700
Subject: [LLVMdev] [unladen-swallow] Re: Why does the x86-64 JIT emit
	stubs for external calls?
In-Reply-To: <35A0A609-B73D-441E-88B8-E7B7B0922B81@apple.com>
References: <bb55930e0906101217v57086e51m25829e61c22e6c7d@mail.gmail.com>
	<35A0A609-B73D-441E-88B8-E7B7B0922B81@apple.com>
Message-ID: <bb55930e0906111624r70e4d962kd35e301379294915@mail.gmail.com>

On Thu, Jun 11, 2009 at 12:54 PM, Evan Cheng<evan.cheng at apple.com> wrote:
>
>
>
> On Jun 10, 2009, at 12:17 PM, Jeffrey Yasskin wrote:
>
>> In X86CodeGen.cpp, the following code appears in the handler used for
>> CALL64pcrel32 instructions:
>>
>>       // Assume undefined functions may be outside the Small codespace.
>>       bool NeedStub =
>>         (Is64BitMode &&
>>             (TM.getCodeModel() == CodeModel::Large ||
>>              TM.getSubtarget<X86Subtarget>().isTargetDarwin())) ||
>>         Opcode == X86::TAILJMPd;
>>       emitGlobalAddress(MO.getGlobal(), X86::reloc_pcrel_word,
>>                         MO.getOffset(), 0, NeedStub);
>>
>> This causes every external call to be emitted as a call to a stub
>> which then jumps to the real function.
>> I understand, thanks to the helpful folks on #llvm, that calls across
>> more than 31 bits of address space need to be emitted as a "mov
>> $ADDRESS, r10; call *r10" pair instead of the simple "call
>> rip+ADDRESS" used for calls within 31 bits. But why isn't the mov+call
>> pair emitted inline? And why are Darwin and TAILJMPs special?
>
> This is needed because of lazy compilation, before the callee is resolved,
> it is just a JIT stub.

Even with lazy compilation, the contents of the stub get emitted (by
JITEmitter::getPointerToGlobal) as a direct call to the function, not
the compilation callback, because the function is an external
declaration. You can watch this happen with the following program:

declare i32 @rand()

define i32 @main() nounwind {
entry:
	%call = tail call i32 @rand()		; <i32> [#uses=1]
	%add = add i32 %call, 2		; <i32> [#uses=1]
	ret i32 %add
}

and the command line `lli -debug-only=jit -march=x86-64 test.bc`.

With lazy compilation and a call to an internal function, the
JITEmitter can emit a stub even if MachineRelocation::doesntNeedStub()
(the field NeedStub gets passed into) returns true. Only returning
false constrains the emitter.

> It's heap allocated so it may not be in the lower 4G
> even if the code size model is small. I know this is the case on Darwin
> x86_64, I am not sure about other targets.

Oh, other targets can certainly allocate code above 4G too.
sys::AllocateRWX just uses mmap with no constraints on the returned
address, and I've got a Linux desktop where that always produces an
address over 4G.

> I forgot why this is needed for
> tail calls, sorry.
>
> In theory we can make the code generator inline mov+call, the reality is it
> doesn't know whether it's jitting or not. Also, we really want to keep the
> code generation the same (as much as possible) whether it's jitting or
> compiling. One possible solution for this is to add code size model
> specifically for JIT so code generator can generate more efficient code in
> that configuration.

For non-JIT, the code generator doesn't ever need a stub, right? The
linker does it using the relocation information? It must be ignoring
the NeedStub parameter. ... But wait, is this code generator used for
anything besides the JIT? Compiling uses the AsmPrinter until direct
object code generation lands, and presumably they're redesigning this
whole subsystem.


It sounds like I'd have to fully understand the whole structure of the
code generator to fix this, and for <=2% performance, that's not
really worth it. I'll probably wait for the direct object code people
to get around to it. Thanks though.

>>
>>
>> Having this out of line seems to lose up to 2% performance on the
>> Unladen Swallow benchmarks, so, while it's not urgent, it'd be nice to
>> figure out how to avoid the stubs.
>>
>> What kind of patch would be welcome to fix this?
>>
>> Thanks,
>> Jeffrey
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>



From aaronngray.lists at googlemail.com  Thu Jun 11 17:56:21 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Fri, 12 Jun 2009 01:56:21 +0100
Subject: [LLVMdev] Why does the x86-64 JIT emit stubs for external calls?
References: <bb55930e0906101217v57086e51m25829e61c22e6c7d@mail.gmail.com>
	<35A0A609-B73D-441E-88B8-E7B7B0922B81@apple.com>
Message-ID: <84EF3C09543C4E6DA1FE0C19DC5EFC5F@HPLAPTOP>

> On Jun 10, 2009, at 12:17 PM, Jeffrey Yasskin wrote:
>
>> In X86CodeGen.cpp, the following code appears in the handler used for
>> CALL64pcrel32 instructions:
>>
>>        // Assume undefined functions may be outside the Small
>> codespace.
>>        bool NeedStub =
>>          (Is64BitMode &&
>>              (TM.getCodeModel() == CodeModel::Large ||
>>               TM.getSubtarget<X86Subtarget>().isTargetDarwin())) ||
>>          Opcode == X86::TAILJMPd;
>>        emitGlobalAddress(MO.getGlobal(), X86::reloc_pcrel_word,
>>                          MO.getOffset(), 0, NeedStub);
>>
>> This causes every external call to be emitted as a call to a stub
>> which then jumps to the real function.
>> I understand, thanks to the helpful folks on #llvm, that calls across
>> more than 31 bits of address space need to be emitted as a "mov
>> $ADDRESS, r10; call *r10" pair instead of the simple "call
>> rip+ADDRESS" used for calls within 31 bits. But why isn't the mov+call
>> pair emitted inline? And why are Darwin and TAILJMPs special?
>
> This is needed because of lazy compilation, before the callee is
> resolved, it is just a JIT stub. It's heap allocated so it may not be
> in the lower 4G even if the code size model is small. I know this is
> the case on Darwin x86_64, I am not sure about other targets. I forgot
> why this is needed for tail calls, sorry.
>
> In theory we can make the code generator inline mov+call, the reality
> is it doesn't know whether it's jitting or not. Also, we really want
> to keep the code generation the same (as much as possible) whether
> it's jitting or compiling. One possible solution for this is to add
> code size model specifically for JIT so code generator can generate
> more efficient code in that configuration.

Since the CodeEmitter's are now generically parameterized they can be 
specialized for JIT quite easily now.

Aaron

>> Having this out of line seems to lose up to 2% performance on the
>> Unladen Swallow benchmarks, so, while it's not urgent, it'd be nice to
>> figure out how to avoid the stubs.
>>
>> What kind of patch would be welcome to fix this?
>>
>> Thanks,
>> Jeffrey
>> _______________________________________________
>> 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 brukman at gmail.com  Thu Jun 11 19:18:25 2009
From: brukman at gmail.com (Misha Brukman)
Date: Thu, 11 Jun 2009 22:18:25 -0400
Subject: [LLVMdev] CROSS COMPILING LLVM
In-Reply-To: <20090610171705.9A51E606897@ws1-4.us4.outblaze.com>
References: <20090610171705.9A51E606897@ws1-4.us4.outblaze.com>
Message-ID: <f88b89a50906111918ja679b19o82b66e0980b9cbbf@mail.gmail.com>

I've committed my scripts that simplify building Linux/x86 -> Linux/ARM
crosstool.  There are 2 parts to using this:

* llvm/utils/crosstool/create-snapshots.sh
  creates tarballs for LLVM and LLVM-GCC from HEAD SVN or a specific
revision of your choice
* llvm/utils/crosstool/ARM/build-install-linux.sh
  builds and installs a Linux/x86 -> Linux/ARM crosstool using the snapshots
generated by the above script.  It also uses the CodeSourcery GCC-based
cross toolchain to avoid having to rebuild cross-binutils and glibc, but if
you don't have it, it'll tell you where to download it from.

Note that HEAD revision of SVN doesn't work for me, but I listed the latest
one I've tried that does, which is 70786.
Let me know if this approach works for you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090611/3d147359/attachment.html>

From mcheva at cs.mcgill.ca  Thu Jun 11 19:51:09 2009
From: mcheva at cs.mcgill.ca (Nyx)
Date: Thu, 11 Jun 2009 19:51:09 -0700 (PDT)
Subject: [LLVMdev] Defining/Accessing Structs Dynamically
In-Reply-To: <f5aa3e9b0906101329t5897a96bx711816cd5fef6f37@mail.gmail.com>
References: <23966736.post@talk.nabble.com>
	<f5aa3e9b0906101329t5897a96bx711816cd5fef6f37@mail.gmail.com>
Message-ID: <23992064.post@talk.nabble.com>


I have most of the code working but I'm running into two issues:

1. I'm not sure exactly how to return a structure on the stack. Right now,
I'm allocating one with alloca, but it seems I can only return a pointer to
it, not the structure itself. Is there any way to dereference the pointer?

2. On the calling side, I get a structure as a return value. However, it
seems GEP is complaining (I get an assertion failure) that I can't do GEP on
a structure object that isn't a pointer. How do I get a pointer to this
return value?

Right now, as a potential solution, I'm actually considering allocating the
structure on the calling side and passing a pointer to it instead, but
perhaps there's a better way to go about this.

- Max
-- 
View this message in context: http://www.nabble.com/Defining-Accessing-Structs-Dynamically-tp23966736p23992064.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.



From eli.friedman at gmail.com  Thu Jun 11 20:13:47 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Thu, 11 Jun 2009 20:13:47 -0700
Subject: [LLVMdev] Defining/Accessing Structs Dynamically
In-Reply-To: <23992064.post@talk.nabble.com>
References: <23966736.post@talk.nabble.com>
	<f5aa3e9b0906101329t5897a96bx711816cd5fef6f37@mail.gmail.com>
	<23992064.post@talk.nabble.com>
Message-ID: <f5aa3e9b0906112013m31a2cb7fwf9900dbfd25147ad@mail.gmail.com>

On Thu, Jun 11, 2009 at 7:51 PM, Nyx<mcheva at cs.mcgill.ca> wrote:
> 1. I'm not sure exactly how to return a structure on the stack. Right now,
> I'm allocating one with alloca, but it seems I can only return a pointer to
> it, not the structure itself. Is there any way to dereference the pointer?

You should be able to do it with the load instruction.

> 2. On the calling side, I get a structure as a return value. However, it
> seems GEP is complaining (I get an assertion failure) that I can't do GEP on
> a structure object that isn't a pointer. How do I get a pointer to this
> return value?

The extractvalue instruction.

> Right now, as a potential solution, I'm actually considering allocating the
> structure on the calling side and passing a pointer to it instead, but
> perhaps there's a better way to go about this.

If you need to interface with C code, this is the only reliable way to do it.

-Eli


From bob.wilson at apple.com  Thu Jun 11 21:46:04 2009
From: bob.wilson at apple.com (Bob Wilson)
Date: Thu, 11 Jun 2009 21:46:04 -0700
Subject: [LLVMdev] CROSS COMPILING LLVM
In-Reply-To: <f88b89a50906111918ja679b19o82b66e0980b9cbbf@mail.gmail.com>
References: <20090610171705.9A51E606897@ws1-4.us4.outblaze.com>
	<f88b89a50906111918ja679b19o82b66e0980b9cbbf@mail.gmail.com>
Message-ID: <0A2B3482-1FB2-4934-B16B-92E070BB6351@apple.com>


On Jun 11, 2009, at 7:18 PM, Misha Brukman wrote:

> I've committed my scripts that simplify building Linux/x86 -> Linux/ 
> ARM crosstool.  There are 2 parts to using this:
>
> * llvm/utils/crosstool/create-snapshots.sh
>   creates tarballs for LLVM and LLVM-GCC from HEAD SVN or a specific  
> revision of your choice
> * llvm/utils/crosstool/ARM/build-install-linux.sh
>   builds and installs a Linux/x86 -> Linux/ARM crosstool using the  
> snapshots generated by the above script.  It also uses the  
> CodeSourcery GCC-based cross toolchain to avoid having to rebuild  
> cross-binutils and glibc, but if you don't have it, it'll tell you  
> where to download it from.
>
> Note that HEAD revision of SVN doesn't work for me, but I listed the  
> latest one I've tried that does, which is 70786.
> Let me know if this approach works for you

Thanks, this should be useful.  What problem did you have with svn  
revisions after 70786?


From marks at dcs.gla.ac.uk  Fri Jun 12 02:48:07 2009
From: marks at dcs.gla.ac.uk (Mark Shannon)
Date: Fri, 12 Jun 2009 10:48:07 +0100
Subject: [LLVMdev] Bug in x86 JIT fast emitter.
Message-ID: <4A322457.8040702@dcs.gla.ac.uk>

Hi there,

I think I've found a bug in the x86 JIT. I get an assertion failure when 
using thread-local variables and the fast emitter.
It only happens with the JIT, the fast emiiter and thread-locals.
(The IR passes the verifier)

Here's the failure:

X86CodeEmitter.cpp:516: void<unnamed>::Emitter::emitInstruction(const 
llvm::MachineInstr&, const llvm::TargetInstrDesc*): Assertion `0 && 
"psuedo instructions should be removed before code emission"' failed.

There is a problem with submitting a bug-report, however.
Since llc has no trouble with thread-locals, I cannot actually generate 
the assertion failure, without my compiler-generator.
I can dump out the IR, but it is rather large.

So,
Is there a way to get llc to use the same emitter as the JIT, so that I
can produce a reasonably sized test-case.

I tried the -fast flag, but it compiles correctly.

Cheers,
Mark.


From fvbommel at wxs.nl  Fri Jun 12 04:06:26 2009
From: fvbommel at wxs.nl (Frits van Bommel)
Date: Fri, 12 Jun 2009 13:06:26 +0200
Subject: [LLVMdev] Bug in x86 JIT fast emitter.
In-Reply-To: <4A322457.8040702@dcs.gla.ac.uk>
References: <4A322457.8040702@dcs.gla.ac.uk>
Message-ID: <4A3236B2.1000303@wxs.nl>

Mark Shannon wrote:
> So,
> Is there a way to get llc to use the same emitter as the JIT, so that I
> can produce a reasonably sized test-case.
> 
> I tried the -fast flag, but it compiles correctly.

Did you try using lli instead of llc?


From nicolas.geoffray at lip6.fr  Fri Jun 12 04:12:10 2009
From: nicolas.geoffray at lip6.fr (Nicolas Geoffray)
Date: Fri, 12 Jun 2009 13:12:10 +0200
Subject: [LLVMdev] Bug in x86 JIT fast emitter.
In-Reply-To: <4A322457.8040702@dcs.gla.ac.uk>
References: <4A322457.8040702@dcs.gla.ac.uk>
Message-ID: <4A32380A.7040806@lip6.fr>

Hi Mark,

Can't we run "lli -fast" on your .bc file instead of llc?

Nicolas

Mark Shannon wrote:
> Hi there,
>
> I think I've found a bug in the x86 JIT. I get an assertion failure when 
> using thread-local variables and the fast emitter.
> It only happens with the JIT, the fast emiiter and thread-locals.
> (The IR passes the verifier)
>
> Here's the failure:
>
> X86CodeEmitter.cpp:516: void<unnamed>::Emitter::emitInstruction(const 
> llvm::MachineInstr&, const llvm::TargetInstrDesc*): Assertion `0 && 
> "psuedo instructions should be removed before code emission"' failed.
>
> There is a problem with submitting a bug-report, however.
> Since llc has no trouble with thread-locals, I cannot actually generate 
> the assertion failure, without my compiler-generator.
> I can dump out the IR, but it is rather large.
>
> So,
> Is there a way to get llc to use the same emitter as the JIT, so that I
> can produce a reasonably sized test-case.
>
> I tried the -fast flag, but it compiles correctly.
>
> Cheers,
> Mark.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   



From marks at dcs.gla.ac.uk  Fri Jun 12 04:35:09 2009
From: marks at dcs.gla.ac.uk (Mark Shannon)
Date: Fri, 12 Jun 2009 12:35:09 +0100
Subject: [LLVMdev] Bug in x86 JIT fast emitter.
In-Reply-To: <4A32380A.7040806@lip6.fr>
References: <4A322457.8040702@dcs.gla.ac.uk> <4A32380A.7040806@lip6.fr>
Message-ID: <4A323D6D.4080708@dcs.gla.ac.uk>

Nicolas, Frits,

I can't run lli directly, because there is no 'main' in my .bc file,
but I should be able to construct a test case.

Thanks,
Mark

Nicolas Geoffray wrote:
> Hi Mark,
> 
> Can't we run "lli -fast" on your .bc file instead of llc?
> 
> Nicolas

Frits van Bommel wrote:
 >
 > Did you try using lli instead of llc?


From deeppatel1987 at gmail.com  Fri Jun 12 08:09:04 2009
From: deeppatel1987 at gmail.com (Sandeep Patel)
Date: Fri, 12 Jun 2009 08:09:04 -0700
Subject: [LLVMdev] ARM backend failures from (gcc) c torture suite
In-Reply-To: <8e3491100906110845u4320e017w81080ce7a9f61fff@mail.gmail.com>
References: <8e3491100906110845u4320e017w81080ce7a9f61fff@mail.gmail.com>
Message-ID: <305d6f60906120809m2cb3766al39399fde5a43ca50@mail.gmail.com>

I don't have a target in front of me to run these tests at the moment,
but walking manually through va-arg-1.c, it's pretty clear that
there's some disconnect between the register spilling that happens in
LowerFORMAL_ARGUMENTS and what happens in LowerVASTART in
ARMISelLowering.cpp.

deep

On Thu, Jun 11, 2009 at 8:45 AM, robert muth<robert at muth.org> wrote:
> I wrote a few scripts to run llvm/arm against the gnu c torture test suite
> which consists of  over 900 smallish tests.
>
> There were quite a few failures with llvm/arm which I hereby want to
> report (see attached
> tarball for the actual failing testsc).
>
> Most of the failures are related to vararg/stdarg.
> I think I saw a bug files for this but cannot find it anymore.
> Is somebody on this?
>
> Finally, I would like to check in the scripts mentioned above.
> What would be a good place for them? "utils/" ?
>
> _______________________________________________
> 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  Fri Jun 12 10:04:20 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Fri, 12 Jun 2009 10:04:20 -0700
Subject: [LLVMdev] Bug in x86 JIT fast emitter.
In-Reply-To: <4A322457.8040702@dcs.gla.ac.uk>
References: <4A322457.8040702@dcs.gla.ac.uk>
Message-ID: <0B8196E1-474C-48AD-A2E2-FDD8A3B42589@apple.com>

X86 JIT does not yet support TLS.

Evan
On Jun 12, 2009, at 2:48 AM, Mark Shannon wrote:

> Hi there,
>
> I think I've found a bug in the x86 JIT. I get an assertion failure  
> when
> using thread-local variables and the fast emitter.
> It only happens with the JIT, the fast emiiter and thread-locals.
> (The IR passes the verifier)
>
> Here's the failure:
>
> X86CodeEmitter.cpp:516: void<unnamed>::Emitter::emitInstruction(const
> llvm::MachineInstr&, const llvm::TargetInstrDesc*): Assertion `0 &&
> "psuedo instructions should be removed before code emission"' failed.
>
> There is a problem with submitting a bug-report, however.
> Since llc has no trouble with thread-locals, I cannot actually  
> generate
> the assertion failure, without my compiler-generator.
> I can dump out the IR, but it is rather large.
>
> So,
> Is there a way to get llc to use the same emitter as the JIT, so  
> that I
> can produce a reasonably sized test-case.
>
> I tried the -fast flag, but it compiles correctly.
>
> Cheers,
> Mark.
> _______________________________________________
> 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  Fri Jun 12 10:07:02 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Fri, 12 Jun 2009 10:07:02 -0700
Subject: [LLVMdev] CROSS COMPILING LLVM
In-Reply-To: <f88b89a50906111918ja679b19o82b66e0980b9cbbf@mail.gmail.com>
References: <20090610171705.9A51E606897@ws1-4.us4.outblaze.com>
	<f88b89a50906111918ja679b19o82b66e0980b9cbbf@mail.gmail.com>
Message-ID: <DC31988E-4FAA-4EEC-B2E6-3718122643A9@apple.com>


On Jun 11, 2009, at 7:18 PM, Misha Brukman wrote:

> I've committed my scripts that simplify building Linux/x86 -> Linux/ 
> ARM crosstool.  There are 2 parts to using this:
>
> * llvm/utils/crosstool/create-snapshots.sh
>   creates tarballs for LLVM and LLVM-GCC from HEAD SVN or a specific  
> revision of your choice
> * llvm/utils/crosstool/ARM/build-install-linux.sh
>   builds and installs a Linux/x86 -> Linux/ARM crosstool using the  
> snapshots generated by the above script.  It also uses the  
> CodeSourcery GCC-based cross toolchain to avoid having to rebuild  
> cross-binutils and glibc, but if you don't have it, it'll tell you  
> where to download it from.

Just a note. CodeSourcery gcc tools is GPLv3. I think referencing the  
tools in a script is fine (except for those of us who are not allowed  
to even use them). But please never bring them into the llvm tree.

Thanks,

Evan

>
>
> Note that HEAD revision of SVN doesn't work for me, but I listed the  
> latest one I've tried that does, which is 70786.
> Let me know if this approach works for you.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



From raj at semihalf.com  Fri Jun 12 10:49:25 2009
From: raj at semihalf.com (Rafal Jaworowski)
Date: Fri, 12 Jun 2009 19:49:25 +0200
Subject: [LLVMdev] Embedded PowerPC support?
Message-ID: <5081764C-3549-4FB0-B4CE-A791EA5E71D3@semihalf.com>

Greetings,
Can anybody comment on LLVM support for the embedded variation of the  
architecture (Book-E: E500, PPC440/460). From a glance I cannot see  
any provisions for such machines, but would like to confirm.

Rafal



From clattner at apple.com  Fri Jun 12 12:00:32 2009
From: clattner at apple.com (Chris Lattner)
Date: Fri, 12 Jun 2009 12:00:32 -0700
Subject: [LLVMdev] Embedded PowerPC support?
In-Reply-To: <5081764C-3549-4FB0-B4CE-A791EA5E71D3@semihalf.com>
References: <5081764C-3549-4FB0-B4CE-A791EA5E71D3@semihalf.com>
Message-ID: <BE19623F-85C4-4171-8BE3-47C799E6E507@apple.com>


On Jun 12, 2009, at 10:49 AM, Rafal Jaworowski wrote:

> Greetings,
> Can anybody comment on LLVM support for the embedded variation of the
> architecture (Book-E: E500, PPC440/460). From a glance I cannot see
> any provisions for such machines, but would like to confirm.

LLVM doesn't have support for these yet, but it should be relatively  
easy to add them if they are just ISA variants.

-Chris


From marks at dcs.gla.ac.uk  Fri Jun 12 13:08:03 2009
From: marks at dcs.gla.ac.uk (Mark Shannon)
Date: Fri, 12 Jun 2009 21:08:03 +0100
Subject: [LLVMdev] Bug in x86 JIT fast emitter.
In-Reply-To: <0B8196E1-474C-48AD-A2E2-FDD8A3B42589@apple.com>
References: <4A322457.8040702@dcs.gla.ac.uk>
	<0B8196E1-474C-48AD-A2E2-FDD8A3B42589@apple.com>
Message-ID: <4A32B5A3.6000205@dcs.gla.ac.uk>

Evan,

Any plans to add it any time soon?
It would be really appreciated.

Evan Cheng wrote:
> X86 JIT does not yet support TLS.
> 
> Evan
> On Jun 12, 2009, at 2:48 AM, Mark Shannon wrote:
> 
>> Hi there,
>>
>> I think I've found a bug in the x86 JIT. I get an assertion failure  
>> when
>> using thread-local variables and the fast emitter.
>> It only happens with the JIT, the fast emiiter and thread-locals.
>> (The IR passes the verifier)
>>
>> Here's the failure:
>>
>> X86CodeEmitter.cpp:516: void<unnamed>::Emitter::emitInstruction(const
>> llvm::MachineInstr&, const llvm::TargetInstrDesc*): Assertion `0 &&
>> "psuedo instructions should be removed before code emission"' failed.
>>
>> There is a problem with submitting a bug-report, however.
>> Since llc has no trouble with thread-locals, I cannot actually  
>> generate
>> the assertion failure, without my compiler-generator.
>> I can dump out the IR, but it is rather large.
>>
>> So,
>> Is there a way to get llc to use the same emitter as the JIT, so  
>> that I
>> can produce a reasonably sized test-case.
>>
>> I tried the -fast flag, but it compiles correctly.
>>
>> Cheers,
>> Mark.
>> _______________________________________________
>> 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 clattner at apple.com  Fri Jun 12 13:57:05 2009
From: clattner at apple.com (Chris Lattner)
Date: Fri, 12 Jun 2009 13:57:05 -0700
Subject: [LLVMdev] Code related to "Run Time Optimization" and
	"Offline	Reoptimizer"
In-Reply-To: <9846fcd40906111345q2705726cy6724db30baadb5d7@mail.gmail.com>
References: <9846fcd40906111345q2705726cy6724db30baadb5d7@mail.gmail.com>
Message-ID: <A7E37E63-C32B-4509-9670-E7F889B46353@apple.com>


On Jun 11, 2009, at 1:45 PM, Kelvin Tian wrote:

> Hi,
>
>     Sorry for this silly question, but I couldn't find the source  
> codes related to "Run Time Optimization" and "Offline Reoptimizer".  
> As there's few references talking about those two parts except for  
> Chris's master thesis. There's a "Runtime" souce code folder, but  
> the codes under that folder mainly relate to gathering profiling  
> information or runtime gc. Can anybody help me point out those two  
> parts of codes in the source code folder? Thanks a lot!

Hi Kelvin,

Those components of LLVM only worked for Sparc and were removed a long  
time (many years) ago, sorry.

-Chris


From gohman at apple.com  Fri Jun 12 14:11:20 2009
From: gohman at apple.com (Dan Gohman)
Date: Fri, 12 Jun 2009 14:11:20 -0700
Subject: [LLVMdev] Tablegen question
In-Reply-To: <68c4c3e20906091316v4df559aex1408c11d8f515f09@mail.gmail.com>
References: <68c4c3e20906060947h7cc89277uf41a0d8c9ffabe89@mail.gmail.com>
	<57C38DA176A0A34A9B9F3CCCE33D3C4AFB244D2ECB@FRPAR1CL009.coe.adi.dibcom.com>
	<68c4c3e20906080958y6ed1ad9ay1d9f5ddd4adcfdf2@mail.gmail.com>
	<B96B557C-F46A-49CD-A6DA-7D3092E74E4F@apple.com>
	<68c4c3e20906081325r193ade4co57841c1f3ed08842@mail.gmail.com>
	<DA634290-3EFD-4ABA-9474-FEFF1EE7E76E@apple.com>
	<68c4c3e20906091316v4df559aex1408c11d8f515f09@mail.gmail.com>
Message-ID: <1DCC419B-D4F4-4BF4-B070-4807491EE493@apple.com>


On Jun 9, 2009, at 1:16 PM, Manjunath Kudlur wrote:


>> All of the tablegen backends work this way. As you mentioned,
>>
>> there are no target-specific tablegen backends at present.
>>
>>
>>
>> The underlying observation here is that features are never
>>
>> fundamentally "specific for a target". For example, a mapping
>>
>> between vector opcodes and associated scalar opcodes could
>>
>> reasonably be made on many architectures. Even
>>
>> load-balancing between functional units on a processor is a
>>
>> target-independent concept, with details like the number and
>>
>> nature of the functional units being target-dependent.
>>
>
> Sorry to be such a pest, but I am still trying to understand the usage
> model for tablegen. Are you saying it is not a good idea to write a
> tablegen backend for something very specific to a target?

The underlying observation here is that features are never
fundamentally "specific for a target".

> The examples
> I gave happen to be applicable to many targets. But the usage depends
> on AN implementation of codegen for a target, no? I mean, I could
> choose to put the related scalar instruction in a field with a
> specific name in the myInst class in the .td file, and would want to
> populate a data structure with a specific name in my C++ code. The
> tablegen backend should "know" the names of both the field in the .td
> file and the name of the data structure. How can I make this generic?

It's hard to say without knowing more details, but in general the
way to do this is to make the data-types used in your C++ code
target-independent. Obviously the actual data would be
target-dependent. Then the code that uses the data structures and
the tablegen backend could both be target-independent.

In general, when features are designed in this way, it is easier
to reuse the code for new targets.

Dan



From haohui.mai at gmail.com  Fri Jun 12 14:52:20 2009
From: haohui.mai at gmail.com (Mai, Haohui)
Date: Fri, 12 Jun 2009 16:52:20 -0500
Subject: [LLVMdev] Proposal for pluggable intrinsics
In-Reply-To: <1DCC419B-D4F4-4BF4-B070-4807491EE493@apple.com>
References: <68c4c3e20906060947h7cc89277uf41a0d8c9ffabe89@mail.gmail.com>
	<57C38DA176A0A34A9B9F3CCCE33D3C4AFB244D2ECB@FRPAR1CL009.coe.adi.dibcom.com>
	<68c4c3e20906080958y6ed1ad9ay1d9f5ddd4adcfdf2@mail.gmail.com>
	<B96B557C-F46A-49CD-A6DA-7D3092E74E4F@apple.com>
	<68c4c3e20906081325r193ade4co57841c1f3ed08842@mail.gmail.com>
	<DA634290-3EFD-4ABA-9474-FEFF1EE7E76E@apple.com>
	<68c4c3e20906091316v4df559aex1408c11d8f515f09@mail.gmail.com>
	<1DCC419B-D4F4-4BF4-B070-4807491EE493@apple.com>
Message-ID: <1244843540.3932.33.camel@haohui-laptop>

Hi all,

Greetings. I'm a Ph.D. student in UIUC. Now I'm working on SAFECode, a
research compiler based on LLVM  which insert necessary runtime checks
to guarantee memory-safety of programs. SAFECode needs to insert checks
into the programs (say, please check this load instruction for me).

Currently SAFECode inserts these checks as normal call instructions. It
would be great that LLVM can treat them as first-class intrinsics (like
"llvm.ctz"), which have additional semantics and could be lowered as
ordinary function calls in subsequent passes.

This would be very useful because 1) It simplifies the analysis logic 2)
LLVM can apply out-of-box compiler optimization technique way more
easily on these programs (for example, SAFECode has special hacks to
teach the LICM pass understand these runtime checks) 3) It completely
avoid the naming conflicts between the tool and the program.

Based on my observation, there are a number of research tools might have
the same requirement above. For instance, Automatic Pool
Allocation(PLDI'05), KLEE(OSDI'08) and SoftBound(PLDI'09) all insert
special intrinsics into programs to perform domain-specific tasks.
Having pluggable, first-class intrinsics would simplify the tasks a lot.

I'm glad to dig in and implement it if you guys are interested. It seems
to me that simply making llvm::CallInst inheritable would be enough.

Comments and suggestions are highly appreciated.

Thanks.

Haohui



From d at time-rover.com  Fri Jun 12 15:57:02 2009
From: d at time-rover.com (Doron Drusinsky (Time Rover Software, Inc.))
Date: Fri, 12 Jun 2009 15:57:02 -0700
Subject: [LLVMdev] LLVM consulting
Message-ID: <5264150F05EC43E38EE4C77815FEF589@Doron>

 

Time Rover Inc. is looking for an off-site LLVM developer and guide for a
short, off-site project that is probably very simple for someone who knows
LLVM. Interested individuals please contact Doron at dorondru at gmail.com

 

Thank you

-Doron

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090612/24979bd7/attachment.html>

From clattner at apple.com  Fri Jun 12 16:16:56 2009
From: clattner at apple.com (Chris Lattner)
Date: Fri, 12 Jun 2009 16:16:56 -0700
Subject: [LLVMdev] Proposal for pluggable intrinsics
In-Reply-To: <1244843540.3932.33.camel@haohui-laptop>
References: <68c4c3e20906060947h7cc89277uf41a0d8c9ffabe89@mail.gmail.com>
	<57C38DA176A0A34A9B9F3CCCE33D3C4AFB244D2ECB@FRPAR1CL009.coe.adi.dibcom.com>
	<68c4c3e20906080958y6ed1ad9ay1d9f5ddd4adcfdf2@mail.gmail.com>
	<B96B557C-F46A-49CD-A6DA-7D3092E74E4F@apple.com>
	<68c4c3e20906081325r193ade4co57841c1f3ed08842@mail.gmail.com>
	<DA634290-3EFD-4ABA-9474-FEFF1EE7E76E@apple.com>
	<68c4c3e20906091316v4df559aex1408c11d8f515f09@mail.gmail.com>
	<1DCC419B-D4F4-4BF4-B070-4807491EE493@apple.com>
	<1244843540.3932.33.camel@haohui-laptop>
Message-ID: <8C6C33B5-8F17-4CD5-8DF2-4AAD6FF90311@apple.com>

On Jun 12, 2009, at 2:52 PM, Mai, Haohui wrote:
> Greetings. I'm a Ph.D. student in UIUC. Now I'm working on SAFECode, a
> research compiler based on LLVM  which insert necessary runtime checks
> to guarantee memory-safety of programs. SAFECode needs to insert  
> checks
> into the programs (say, please check this load instruction for me).

Hi.

> Currently SAFECode inserts these checks as normal call instructions.  
> It
> would be great that LLVM can treat them as first-class intrinsics  
> (like
> "llvm.ctz"), which have additional semantics and could be lowered as
> ordinary function calls in subsequent passes.

I was just about to recommend using normal function calls :).

> This would be very useful because 1) It simplifies the analysis  
> logic 2)
> LLVM can apply out-of-box compiler optimization technique way more
> easily on these programs (for example, SAFECode has special hacks to
> teach the LICM pass understand these runtime checks) 3) It completely
> avoid the naming conflicts between the tool and the program.

I don't follow.  Why does it simplify the analysis logic?  Also,  
aren't function attributes like "readonly" enough to teach the  
optimizer about your functions?

-Chris



From haohui.mai at gmail.com  Fri Jun 12 18:26:19 2009
From: haohui.mai at gmail.com (Mai, Haohui)
Date: Fri, 12 Jun 2009 20:26:19 -0500
Subject: [LLVMdev] Proposal for pluggable intrinsics
In-Reply-To: <8C6C33B5-8F17-4CD5-8DF2-4AAD6FF90311@apple.com>
References: <68c4c3e20906060947h7cc89277uf41a0d8c9ffabe89@mail.gmail.com>
	<57C38DA176A0A34A9B9F3CCCE33D3C4AFB244D2ECB@FRPAR1CL009.coe.adi.dibcom.com>
	<68c4c3e20906080958y6ed1ad9ay1d9f5ddd4adcfdf2@mail.gmail.com>
	<B96B557C-F46A-49CD-A6DA-7D3092E74E4F@apple.com>
	<68c4c3e20906081325r193ade4co57841c1f3ed08842@mail.gmail.com>
	<DA634290-3EFD-4ABA-9474-FEFF1EE7E76E@apple.com>
	<68c4c3e20906091316v4df559aex1408c11d8f515f09@mail.gmail.com>
	<1DCC419B-D4F4-4BF4-B070-4807491EE493@apple.com>
	<1244843540.3932.33.camel@haohui-laptop>
	<8C6C33B5-8F17-4CD5-8DF2-4AAD6FF90311@apple.com>
Message-ID: <1244856379.3699.1.camel@haohui-laptop>

On Fri, 2009-06-12 at 16:16 -0700, Chris Lattner wrote:
> On Jun 12, 2009, at 2:52 PM, Mai, Haohui wrote:
> > Greetings. I'm a Ph.D. student in UIUC. Now I'm working on SAFECode, a
> > research compiler based on LLVM  which insert necessary runtime checks
> > to guarantee memory-safety of programs. SAFECode needs to insert  
> > checks
> > into the programs (say, please check this load instruction for me).
> 
> Hi.
> 
> > Currently SAFECode inserts these checks as normal call instructions.  
> > It
> > would be great that LLVM can treat them as first-class intrinsics  
> > (like
> > "llvm.ctz"), which have additional semantics and could be lowered as
> > ordinary function calls in subsequent passes.
> 
> I was just about to recommend using normal function calls :).
> 
> > This would be very useful because 1) It simplifies the analysis  
> > logic 2)
> > LLVM can apply out-of-box compiler optimization technique way more
> > easily on these programs (for example, SAFECode has special hacks to
> > teach the LICM pass understand these runtime checks) 3) It completely
> > avoid the naming conflicts between the tool and the program.
> 
> I don't follow.  Why does it simplify the analysis logic?  Also,  
> aren't function attributes like "readonly" enough to teach the  
> optimizer about your functions?

In fact, they are not really "readonly" functions. These checking
functions manipulate some metadata. If they are marked as readonly,
ADCE will kill them. :-)

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



From marks at dcs.gla.ac.uk  Sat Jun 13 03:37:46 2009
From: marks at dcs.gla.ac.uk (Mark Shannon)
Date: Sat, 13 Jun 2009 11:37:46 +0100
Subject: [LLVMdev] What happened to the -fast flag for lli?
In-Reply-To: <0B8196E1-474C-48AD-A2E2-FDD8A3B42589@apple.com>
References: <4A322457.8040702@dcs.gla.ac.uk>
	<0B8196E1-474C-48AD-A2E2-FDD8A3B42589@apple.com>
Message-ID: <4A33817A.3040208@dcs.gla.ac.uk>

Hi,

I've just installed llvm from trunk and
lli seems to have lost the -fast option.

Can we have it back please?

Mark.


From wesley at terpstra.ca  Sat Jun 13 03:54:06 2009
From: wesley at terpstra.ca (Wesley W. Terpstra)
Date: Sat, 13 Jun 2009 12:54:06 +0200
Subject: [LLVMdev] ML types in LLVM
Message-ID: <162de7480906130354m430f9e17ndbf03b41592ab982@mail.gmail.com>

Good afternoon!

I'm trying to write an LLVM codegen for a Standard ML compiler
(MLton). So far things seem to match up quite nicely, but I have hit
two sticking points. I'm hoping LLVM experts might know how to handle
these two cases better.

1: In ML we have some types that are actually one of several possible
types. Expressed in C this might be thought of as a union. The codegen
only ever accesses these 'union types' via pointer. Before actually
indexing into the type, it always casts from the 'union pointer type'
to a specific pointer type.

As a concrete example. I have two types %a and %b. I want to express a
third type %c that is either %a* or %b*. Later I'll cast the %c to
either %a* or %b*.

Currently I just represent %c as i8*. I assume that this can have
consequences in terms of aliasing. I tried opaque*, but llvm-as didn't
like that. Is there any way to better represent the type %c to LLVM?

2: In the ML heap we have objects that are garbage collected. Objects
are preceded by a header that describes the object to the garbage
collector. However, pointers to the objects point past the header and
at the actual object. Sometimes, however, the program itself accesses
the header. For example, to determine the length of an array (the
length is in the header). For every type I output it like this:

%opt_33 = { i32, %opt_45*, float }

I could also create another type which includes the header something like:
%opt_33_with_header = {i32, %opt_33 }

Is there any way to express that a pointer is actually a pointer to an
interior element of a type? Something like %opt_33_in_heap =
%opt_33_with_header:1 ?

Currently when I want to read the header of an %opt_33, I cast it to a
i32* and then use getelementptr -1. Is there a better way?


From marks at dcs.gla.ac.uk  Sat Jun 13 04:02:16 2009
From: marks at dcs.gla.ac.uk (Mark Shannon)
Date: Sat, 13 Jun 2009 12:02:16 +0100
Subject: [LLVMdev] What happened to the -fast flag for lli?
In-Reply-To: <4A33817A.3040208@dcs.gla.ac.uk>
References: <4A322457.8040702@dcs.gla.ac.uk>	<0B8196E1-474C-48AD-A2E2-FDD8A3B42589@apple.com>
	<4A33817A.3040208@dcs.gla.ac.uk>
Message-ID: <4A338738.10201@dcs.gla.ac.uk>

Hi,
I'm slightly confused here.

Not only, has -fast flag disappeared from lli,
the ExecutionEngine:createJIT API has changed as well.
I suspect these are related :)

What will this do to the speed of JIT code generation?
What effect do the new optimisation levels in ExecutionEngine:createJIT 
have?
What lli flag (if any) corresponds to these optimisation levels?
And is this documented anywhere?

Mark.


From samuraileumas at yahoo.com  Sat Jun 13 08:59:46 2009
From: samuraileumas at yahoo.com (Samuel Crow)
Date: Sat, 13 Jun 2009 08:59:46 -0700 (PDT)
Subject: [LLVMdev] What happened to the -fast flag for lli?
In-Reply-To: <4A338738.10201@dcs.gla.ac.uk>
References: <4A322457.8040702@dcs.gla.ac.uk>
	<0B8196E1-474C-48AD-A2E2-FDD8A3B42589@apple.com>
	<4A33817A.3040208@dcs.gla.ac.uk> <4A338738.10201@dcs.gla.ac.uk>
Message-ID: <844159.42563.qm@web62006.mail.re1.yahoo.com>


Hello Mark,

It's not a flag anymore, it is an enumeration.  See http://www.nabble.com/Change-in-JIT-td23308581.html#a23308581 for details.

--Sam



----- Original Message ----
> From: Mark Shannon <marks at dcs.gla.ac.uk>
> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Sent: Saturday, June 13, 2009 6:02:16 AM
> Subject: Re: [LLVMdev] What happened to the -fast flag for lli?
> 
> Hi,
> I'm slightly confused here.
> 
> Not only, has -fast flag disappeared from lli,
> the ExecutionEngine:createJIT API has changed as well.
> I suspect these are related :)
> 
> What will this do to the speed of JIT code generation?
> What effect do the new optimisation levels in ExecutionEngine:createJIT 
> have?
> What lli flag (if any) corresponds to these optimisation levels?
> And is this documented anywhere?
> 
> Mark.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



      


From clattner at apple.com  Sat Jun 13 10:25:48 2009
From: clattner at apple.com (Chris Lattner)
Date: Sat, 13 Jun 2009 10:25:48 -0700
Subject: [LLVMdev] Regular Expressions
In-Reply-To: <200906111601.57203.dag@cray.com>
References: <200906081700.n58H0Zvi022899@zion.cs.uiuc.edu>
	<200906091439.18446.dag@cray.com>
	<21EF7717-A7BE-44EE-B320-53A6BEEAE8EF@apple.com>
	<200906111601.57203.dag@cray.com>
Message-ID: <3BD935DB-2D5B-4AC4-BD12-EDDE9F959757@apple.com>

On Jun 11, 2009, at 2:01 PM, David Greene wrote:
> On Thursday 11 June 2009 12:28, Chris Lattner wrote:
>>>
>>> Yes.  I want TableGen to be able to infer lots of stuff
>>> programmatically.
>>> This helps tremendously when specifying things like, oh, AVX.  :)
>>
>> I don't see how this relates to regex's, and really don't want to  
>> suck
>> in an external regex library.  Can you give an example of how this
>> would help?
>
> Sure:
>
> [Top-level specification]
> defm CVTSI2SS :  
> sse1_avx_fp_cvt_scalar_xs_scalar64_xs_node_sintrinsic_rm<
>  0x2D, "cvtsi2ss", sint_to_fp, "cvtsi2ss", "f32", "i32">;
>
> [Meanwhile, down in the guts...]
>
> class fp_cvt_scalar_VXSnrr<
> // Parent: avx_fp_cvt_scalar_xs_node_rm_DEF_V#NAME#_128rr
>  bits<8> opc,
>  string OpcodeStr,
>  SDNode OpNode,
>  string DstType,
>  string SrcType,
>  int CustomPatterns = 0,
>  list<dag> patterns = [],
>  string asm = ""
>> : fp_unary_vxs_n_rm_rr<
>    opc,
>    !cast<RegisterClass>(!patsubst("^f([0-9]+)","FR$1",! 
> patsubst("^i([0-9]+)","GR$1",DstType))),
> [...]

Very clever.

> Basically, the code keys off type strings to deduce register classes  
> and
> other such things.  This makes specifying things like converts much  
> easier
> because one doesn't need to pass a bunch of additional parameters  
> around to
> specify register classes, etc. when it is entirely obvious what they  
> should be
> given other parameters.
>
> I'm trying to reduce the number of classes/parameters to deal with  
> so I
> can eventually get rid of the Perl script that's generating most of  
> this
> stuff right now.  This kind of pattern matching and substitution  
> really
> helps simplify things to a point where I can imagine manually  
> maintaining
> a smaller amount of information.

Right, I definitely agree with your goal of reducing redundancy in  
the .td files! :)

However, I don't see any reason to base this off of strings.  Instead  
of passing down "f32" as a string, why not do something like this  
pseudo code:

class X86ValueType {
   RegisterClass RegClass;
   ...
}

def X86_f32 : X86ValueType {
   let RegClass = FR32;
   ... };
def X86_i32 : X86ValueType { ... };

Then change fp_cvt_scalar_VXSnrr to be something like this:

> class fp_cvt_scalar_VXSnrr<
> // Parent: avx_fp_cvt_scalar_xs_node_rm_DEF_V#NAME#_128rr
>  bits<8> opc,
>  string OpcodeStr,
>  SDNode OpNode,
>  X86ValueType DstType,
>  X86ValueType SrcType,
>  int CustomPatterns = 0,
>  list<dag> patterns = [],
>  string asm = ""
>> : fp_unary_vxs_n_rm_rr<
>    opc, DstType.RegClass,

This lets you encode whatever you want as properties of the dependent  
class, makes everything "type safe", and eliminates string munging.   
Would something like this work?

-Chris



From aaronngray.lists at googlemail.com  Sat Jun 13 11:45:42 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Sat, 13 Jun 2009 19:45:42 +0100
Subject: [LLVMdev] PIC documentation ?
Message-ID: <8653927FD91A400AB077D2EF48F7132D@HPLAPTOP>

Is there any overview or detailed socumentation on LLVM PIC ?

Many thanks in advance,

Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090613/8b6b5719/attachment.html>

From rjmccall at apple.com  Sat Jun 13 12:44:10 2009
From: rjmccall at apple.com (John McCall)
Date: Sat, 13 Jun 2009 12:44:10 -0700
Subject: [LLVMdev] ML types in LLVM
In-Reply-To: <162de7480906130354m430f9e17ndbf03b41592ab982@mail.gmail.com>
References: <162de7480906130354m430f9e17ndbf03b41592ab982@mail.gmail.com>
Message-ID: <B4B325FE-9632-4767-85DD-896F7A8D5000@apple.com>

On Jun 13, 2009, at 3:54 AM, Wesley W. Terpstra wrote:
> Currently I just represent %c as i8*. I assume that this can have
> consequences in terms of aliasing. I tried opaque*, but llvm-as didn't
> like that. Is there any way to better represent the type %c to LLVM?

I assume this is for tagged sums.

Logically, what you want is a distinct LLVM type for every ML union type
and each of its constructors.  Unfortunately, LLVM does structural
uniquing of types, so that won't work.  What you can do is abuse address
spaces, giving every distinct type its own address space and casting
back and forth between address spaces as necessary.

> Is there any way to express that a pointer is actually a pointer to an
> interior element of a type? Something like %opt_33_in_heap =
> %opt_33_with_header:1 ?

Something like an ungetelementptr?  No, sorry.  That would be a
pretty nice extension, though obviously unsound, of course.

> Currently when I want to read the header of an %opt_33, I cast it to a
> i32* and then use getelementptr -1. Is there a better way?

I think it depends on (1) exactly how your runtime environment lays out
the header and (2) whether you're trying to create portable IR (as  
opposed
to creating IR portably).

Personally, I would create a struct type (hereafter "HeaderType") for  
the
entire GC header;  when you want to access a header field, just cast the
base pointer to i8*, subtract the allocation size of HeaderType, cast  
the
result to HeaderType*, and getelementptr from there.  That doesn't
make portable IR, of course, but in the absence of an ungetelementptr
instruction, I'm not sure how you could do that better.

You can portably get the allocation size of a type using
TargetData::getTypeSizeInBits().

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090613/eaa8566d/attachment.html>

From deano at zombiehousestudios.com  Sat Jun 13 13:53:31 2009
From: deano at zombiehousestudios.com (Dean Calver)
Date: Sat, 13 Jun 2009 21:53:31 +0100
Subject: [LLVMdev] Bug in CMake Xcode projects
Message-ID: <84C4276B-018C-4688-BB96-6DF25FBB4B90@zombiehousestudios.com>

Hi

I'm using CMake on OSX to generate Xcode projects and compile from  
there, however it appears to have problems with the _pll libraries?

Each _pll library depends on the non _pll version, i.e. LLVMJIT_pll  
links to libLLVMJIT.a, however it cannot find the non _pll library  
even though it claims it has been build already.

I suspect its a pathing issue, and I'm about to dig into the CMake  
files to see if I can work it out but figured I'd post here for some  
expert knowledge.

There are further failures later on, but I think they might be knock  
on from the above link problems (there are half a dozen of the _pll  
issues...)

Thanks,
Deano


From evan.cheng at apple.com  Sat Jun 13 14:22:00 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Sat, 13 Jun 2009 14:22:00 -0700
Subject: [LLVMdev] Bug in x86 JIT fast emitter.
In-Reply-To: <4A32B5A3.6000205@dcs.gla.ac.uk>
References: <4A322457.8040702@dcs.gla.ac.uk>
	<0B8196E1-474C-48AD-A2E2-FDD8A3B42589@apple.com>
	<4A32B5A3.6000205@dcs.gla.ac.uk>
Message-ID: <598B4D88-74C4-4319-82F1-DC6CCD14B0D2@apple.com>

No plans. I recommend you hack on it. :-) Sorry, all features are done  
on demand.

Evan

On Jun 12, 2009, at 1:08 PM, Mark Shannon wrote:

> Evan,
>
> Any plans to add it any time soon?
> It would be really appreciated.
>
> Evan Cheng wrote:
>> X86 JIT does not yet support TLS.
>>
>> Evan
>> On Jun 12, 2009, at 2:48 AM, Mark Shannon wrote:
>>
>>> Hi there,
>>>
>>> I think I've found a bug in the x86 JIT. I get an assertion failure
>>> when
>>> using thread-local variables and the fast emitter.
>>> It only happens with the JIT, the fast emiiter and thread-locals.
>>> (The IR passes the verifier)
>>>
>>> Here's the failure:
>>>
>>> X86CodeEmitter.cpp:516:  
>>> void<unnamed>::Emitter::emitInstruction(const
>>> llvm::MachineInstr&, const llvm::TargetInstrDesc*): Assertion `0 &&
>>> "psuedo instructions should be removed before code emission"'  
>>> failed.
>>>
>>> There is a problem with submitting a bug-report, however.
>>> Since llc has no trouble with thread-locals, I cannot actually
>>> generate
>>> the assertion failure, without my compiler-generator.
>>> I can dump out the IR, but it is rather large.
>>>
>>> So,
>>> Is there a way to get llc to use the same emitter as the JIT, so
>>> that I
>>> can produce a reasonably sized test-case.
>>>
>>> I tried the -fast flag, but it compiles correctly.
>>>
>>> Cheers,
>>> Mark.
>>> _______________________________________________
>>> 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
>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



From wesley at terpstra.ca  Sat Jun 13 17:14:19 2009
From: wesley at terpstra.ca (Wesley W. Terpstra)
Date: Sun, 14 Jun 2009 02:14:19 +0200
Subject: [LLVMdev] ML types in LLVM
In-Reply-To: <B4B325FE-9632-4767-85DD-896F7A8D5000@apple.com>
References: <162de7480906130354m430f9e17ndbf03b41592ab982@mail.gmail.com>
	<B4B325FE-9632-4767-85DD-896F7A8D5000@apple.com>
Message-ID: <162de7480906131714s48a56b16v9464f8040ee61710@mail.gmail.com>

On Sat, Jun 13, 2009 at 9:44 PM, John McCall<rjmccall at apple.com> wrote:
> On Jun 13, 2009, at 3:54 AM, Wesley W. Terpstra wrote:
> Currently I just represent %c as i8*. I assume that this can have
> consequences in terms of aliasing. I tried opaque*, but llvm-as didn't
> like that. Is there any way to better represent the type %c to LLVM?
>
> I assume this is for tagged sums.

Yes.

> Logically, what you want is a distinct LLVM type for every ML union type
> and each of its constructors.  Unfortunately, LLVM does structural
> uniquing of types, so that won't work.

Is there absolutely no way to generate a new type? Not even an 'opaque' one?

> What you can do is abuse address
> spaces, giving every distinct type its own address space and casting
> back and forth between address spaces as necessary.

The manual indicates that only addresses in space 0 can have GC
intrinsics used on them. Also I get the impression that this would be
a pretty unsafe idea. ;)

> Is there any way to express that a pointer is actually a pointer to an
> interior element of a type? Something like %opt_33_in_heap =
> %opt_33_with_header:1 ?
>
> Something like an ungetelementptr?  No, sorry.  That would be a
> pretty nice extension, though obviously unsound, of course.

Well, ungetelementptr could be nice, but I was hoping for something
even better: a way to refer to the whole object type (including the
header) even though my pointer doesn't point to the start of the
object. Ie: this is a pointer to 8 bytes past type X.

That way for normal access I punch down to the object part of the type
and do my business. For access to the header, I just punch into that
part of the type (which happens to involve a negative offset from the
address). However, it seems that LLVM pointers always have to point to
the start of an object.

> Personally, I would create a struct type (hereafter "HeaderType") for the
> entire GC header;  when you want to access a header field, just cast the
> base pointer to i8*, subtract the allocation size of HeaderType, cast the
> result to HeaderType*, and getelementptr from there.

That's what I'm doing right now; the HeaderType happens to be i32. ;)
I am assuming that casting in and out of i8* will cost me in terms of
the optimizations LLVM can apply..?

Also, I couldn't find a no-op instruction in LLVM. In some places it
would be convenient to say: '%x = %y'. For the moment I'm doing a
bitcast from the type back to itself, which is rather awkward.



From jon at ffconsultancy.com  Sat Jun 13 18:54:19 2009
From: jon at ffconsultancy.com (Jon Harrop)
Date: Sun, 14 Jun 2009 02:54:19 +0100
Subject: [LLVMdev] ML types in LLVM
In-Reply-To: <162de7480906130354m430f9e17ndbf03b41592ab982@mail.gmail.com>
References: <162de7480906130354m430f9e17ndbf03b41592ab982@mail.gmail.com>
Message-ID: <200906140254.19144.jon@ffconsultancy.com>

On Saturday 13 June 2009 11:54:06 Wesley W. Terpstra wrote:
> Good afternoon!
>
> I'm trying to write an LLVM codegen for a Standard ML compiler
> (MLton)...

You may be interested in my HLVM project, a VM built upon LLVM and designed 
for MLs:

  http://hlvm.forge.ocamlcore.org

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e


From eric at brouhaha.com  Sat Jun 13 18:59:18 2009
From: eric at brouhaha.com (Eric Smith)
Date: Sat, 13 Jun 2009 18:59:18 -0700
Subject: [LLVMdev] making trampolines more portable
Message-ID: <4A345976.3000303@brouhaha.com>

I'm not sure whether there are any other cases where using LLVM requires 
knowledge of the target architecture, but needing it for trampolines is 
worrying me.  I'm putting together things where the program that's 
generating the LLVM intermediate code doesn't have any way to know what 
the target architecture will be.

Right now I'm using alloca to get a block that is expected to be more 
than large enough, and assuming that align 4 will work.  Any chance of 
LLVM gaining a new intrinsic that returns the appropriate size and 
alignment for the target?  (Might need the alloca() instruction extended 
or a new version to support non-constant alignment?)

Thanks!
Eric



From nicholas at mxc.ca  Sat Jun 13 19:32:43 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Sat, 13 Jun 2009 19:32:43 -0700
Subject: [LLVMdev] ML types in LLVM
In-Reply-To: <162de7480906131714s48a56b16v9464f8040ee61710@mail.gmail.com>
References: <162de7480906130354m430f9e17ndbf03b41592ab982@mail.gmail.com>	<B4B325FE-9632-4767-85DD-896F7A8D5000@apple.com>
	<162de7480906131714s48a56b16v9464f8040ee61710@mail.gmail.com>
Message-ID: <4A34614B.4010901@mxc.ca>

Wesley W. Terpstra wrote:
> On Sat, Jun 13, 2009 at 9:44 PM, John McCall<rjmccall at apple.com> wrote:
>> On Jun 13, 2009, at 3:54 AM, Wesley W. Terpstra wrote:
>> Currently I just represent %c as i8*. I assume that this can have
>> consequences in terms of aliasing. I tried opaque*, but llvm-as didn't
>> like that. Is there any way to better represent the type %c to LLVM?
>>
>> I assume this is for tagged sums.
> 
> Yes.
> 
>> Logically, what you want is a distinct LLVM type for every ML union type
>> and each of its constructors.  Unfortunately, LLVM does structural
>> uniquing of types, so that won't work.
> 
> Is there absolutely no way to generate a new type? Not even an 'opaque' one?

Each time you say "opaque" in a .ll (or call OpaqueType::get in the C++ 
API) you get yourself a new distinct opaque type.

It's not clear to me at all why opaque didn't work for you in the first 
place. One thing you'll have to remember is that because of the above, 
if you want to take an opaque* and pass it to another function that 
takes an opaque*, you'll get a type mismatch since you said opaque 
twice. Use "%c = type opaque" in the global space, then %c* to get the 
same opaque in multiple places. The other reason it might not have 
worked for you is that you might've tried to dereference your opaque* 
thereby producing just 'opaque' which isn't allowed.

>>  What you can do is abuse address
>> spaces, giving every distinct type its own address space and casting
>> back and forth between address spaces as necessary.
> 
> The manual indicates that only addresses in space 0 can have GC
> intrinsics used on them. Also I get the impression that this would be
> a pretty unsafe idea. ;)
> 
>> Is there any way to express that a pointer is actually a pointer to an
>> interior element of a type? Something like %opt_33_in_heap =
>> %opt_33_with_header:1 ?
>>
>> Something like an ungetelementptr?  No, sorry.  That would be a
>> pretty nice extension, though obviously unsound, of course.
> 
> Well, ungetelementptr could be nice, but I was hoping for something
> even better: a way to refer to the whole object type (including the
> header) even though my pointer doesn't point to the start of the
> object. Ie: this is a pointer to 8 bytes past type X.
> 
> That way for normal access I punch down to the object part of the type
> and do my business. For access to the header, I just punch into that
> part of the type (which happens to involve a negative offset from the
> address). However, it seems that LLVM pointers always have to point to
> the start of an object.
> 
>> Personally, I would create a struct type (hereafter "HeaderType") for the
>> entire GC header;  when you want to access a header field, just cast the
>> base pointer to i8*, subtract the allocation size of HeaderType, cast the
>> result to HeaderType*, and getelementptr from there.
> 
> That's what I'm doing right now; the HeaderType happens to be i32. ;)
> I am assuming that casting in and out of i8* will cost me in terms of
> the optimizations LLVM can apply..?
> 
> Also, I couldn't find a no-op instruction in LLVM. In some places it
> would be convenient to say: '%x = %y'. For the moment I'm doing a
> bitcast from the type back to itself, which is rather awkward.

There is none, using a bitcast is the workaround. LLVM's optimizers will 
fix it up.

Nick


From eli.friedman at gmail.com  Sat Jun 13 20:12:57 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Sat, 13 Jun 2009 20:12:57 -0700
Subject: [LLVMdev] making trampolines more portable
In-Reply-To: <4A345976.3000303@brouhaha.com>
References: <4A345976.3000303@brouhaha.com>
Message-ID: <f5aa3e9b0906132012k213555cdt932f1cab2cb0b6aa@mail.gmail.com>

On Sat, Jun 13, 2009 at 6:59 PM, Eric Smith<eric at brouhaha.com> wrote:
> Right now I'm using alloca to get a block that is expected to be more
> than large enough, and assuming that align 4 will work.  Any chance of
> LLVM gaining a new intrinsic that returns the appropriate size and
> alignment for the target?  (Might need the alloca() instruction extended
> or a new version to support non-constant alignment?)

The alignment is easy: just allocate as an array of pointers, and I'm
pretty sure you'll get appropriate alignment for every architecture.
Also, for lack of an intrinsic, there's a relatively easy workaround:
you can declare a global containing the correct size, then link in a
small target-specific .bc with the definition right before code
generation.

-Eli



From suigintou_ at hotmail.com  Sat Jun 13 22:41:27 2009
From: suigintou_ at hotmail.com (seventh moon)
Date: Sun, 14 Jun 2009 13:41:27 +0800
Subject: [LLVMdev] A question about printout the SeletionDAG
Message-ID: <BAY114-W3672086826DBAA999ADA41F1410@phx.gbl>


commend "llvm-dis" can print out the LLVM IR

 

but is there any way to printout the SelectionDAG?
like: add (x , add (y,z))

Thank you for your assistance,
Kao Chang

_________________________________________________________________
用部落格分享照片、影音、趣味小工具和最愛清單，盡情秀出你自己 — Windows Live Spaces
http://home.spaces.live.com/?showUnauth=1&lc=1028
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090614/001e7ae2/attachment.html>

From eli.friedman at gmail.com  Sat Jun 13 22:59:33 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Sat, 13 Jun 2009 22:59:33 -0700
Subject: [LLVMdev] A question about printout the SeletionDAG
In-Reply-To: <BAY114-W3672086826DBAA999ADA41F1410@phx.gbl>
References: <BAY114-W3672086826DBAA999ADA41F1410@phx.gbl>
Message-ID: <f5aa3e9b0906132259s2052a409of9788c2a60ba91d4@mail.gmail.com>

2009/6/13 seventh moon <suigintou_ at hotmail.com>:
> commend "llvm-dis" can print out the LLVM IR
>
> but is there any way to printout the SelectionDAG?
> like: add (x , add (y,z))

Try passing -debug to llc.  Alternatively, you can use the options
like -view-isel-dags to get a pretty graph; there's a complete list of
the options in llc --help-hidden.

-Eli



From fw at deneb.enyo.de  Sun Jun 14 01:50:29 2009
From: fw at deneb.enyo.de (Florian Weimer)
Date: Sun, 14 Jun 2009 10:50:29 +0200
Subject: [LLVMdev] ML types in LLVM
In-Reply-To: <162de7480906131714s48a56b16v9464f8040ee61710@mail.gmail.com>
	(Wesley W. Terpstra's message of "Sun, 14 Jun 2009 02:14:19 +0200")
References: <162de7480906130354m430f9e17ndbf03b41592ab982@mail.gmail.com>
	<B4B325FE-9632-4767-85DD-896F7A8D5000@apple.com>
	<162de7480906131714s48a56b16v9464f8040ee61710@mail.gmail.com>
Message-ID: <877hzfqjvu.fsf@mid.deneb.enyo.de>

* Wesley W. Terpstra:

>> Logically, what you want is a distinct LLVM type for every ML union type
>> and each of its constructors.  Unfortunately, LLVM does structural
>> uniquing of types, so that won't work.
>
> Is there absolutely no way to generate a new type? Not even an
> 'opaque' one?

Is this really a problem for MLton?  I think you only get less precise
alias analysis, and that's it.



From marks at dcs.gla.ac.uk  Sun Jun 14 03:06:47 2009
From: marks at dcs.gla.ac.uk (Mark Shannon)
Date: Sun, 14 Jun 2009 11:06:47 +0100
Subject: [LLVMdev] Bug in x86 JIT fast emitter.
In-Reply-To: <598B4D88-74C4-4319-82F1-DC6CCD14B0D2@apple.com>
References: <4A322457.8040702@dcs.gla.ac.uk>	<0B8196E1-474C-48AD-A2E2-FDD8A3B42589@apple.com>	<4A32B5A3.6000205@dcs.gla.ac.uk>
	<598B4D88-74C4-4319-82F1-DC6CCD14B0D2@apple.com>
Message-ID: <4A34CBB7.3020507@dcs.gla.ac.uk>

Evan Cheng wrote:
> No plans. I recommend you hack on it. :-) Sorry, all features are done  
> on demand.

Can I "demand" it then :)

Can't do any hacking myself for three weeks, but I'll have a try at 
fixing it after that (C++ is not really my strong point).

Cheers,
Mark
> 
> Evan
> 
> On Jun 12, 2009, at 1:08 PM, Mark Shannon wrote:
> 
>> Evan,
>>
>> Any plans to add it any time soon?
>> It would be really appreciated.
>>
>> Evan Cheng wrote:
>>> X86 JIT does not yet support TLS.
>>>
>>> Evan
>>> On Jun 12, 2009, at 2:48 AM, Mark Shannon wrote:
>>>
>>>> Hi there,
>>>>
>>>> I think I've found a bug in the x86 JIT. I get an assertion failure
>>>> when
>>>> using thread-local variables and the fast emitter.
>>>> It only happens with the JIT, the fast emiiter and thread-locals.
>>>> (The IR passes the verifier)
>>>>
>>>> Here's the failure:
>>>>
>>>> X86CodeEmitter.cpp:516:  
>>>> void<unnamed>::Emitter::emitInstruction(const
>>>> llvm::MachineInstr&, const llvm::TargetInstrDesc*): Assertion `0 &&
>>>> "psuedo instructions should be removed before code emission"'  
>>>> failed.
>>>>
>>>> There is a problem with submitting a bug-report, however.
>>>> Since llc has no trouble with thread-locals, I cannot actually
>>>> generate
>>>> the assertion failure, without my compiler-generator.
>>>> I can dump out the IR, but it is rather large.
>>>>
>>>> So,
>>>> Is there a way to get llc to use the same emitter as the JIT, so
>>>> that I
>>>> can produce a reasonably sized test-case.
>>>>
>>>> I tried the -fast flag, but it compiles correctly.
>>>>
>>>> Cheers,
>>>> Mark.
>>>> _______________________________________________
>>>> 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
>>>
>> _______________________________________________
>> 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 hannibal_08 at mail.com  Sun Jun 14 04:19:11 2009
From: hannibal_08 at mail.com (hannibal hannibal)
Date: Sun, 14 Jun 2009 06:19:11 -0500
Subject: [LLVMdev] CROSS COMPILING LLVM
Message-ID: <20090614111911.EC16A1CE833@ws1-6.us4.outblaze.com>

 I was able to use your scripts to build� llvm and llvm-gcc successfully.
But when i try to link to llvm libraries i get the following :

.........................
..........................
/arm-2007q3/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.1/../../../../arm-none-linux-gnueabi/bin/ld:
/arm-llvm/llvm-project/i686-pc-linux-gnu/arm-none-linux-gnueabi/llvm/lib/LLVMXCore.o:
Relocations in generic ELF (EM: 3)
/arm-llvm/llvm-project/i686-pc-linux-gnu/arm-none-linux-gnueabi/llvm/lib/LLVMXCore.o:
could not read symbols: File in wrong format


Thanks
Hannibal


  ----- Original Message -----
  From: "Misha Brukman"
  To: "LLVM Developers Mailing List"
  Subject: Re: [LLVMdev] CROSS COMPILING LLVM
  Date: Thu, 11 Jun 2009 22:18:25 -0400

  I've committed my scripts that simplify building Linux/x86 ->
  Linux/ARM crosstool.� There are 2 parts to using this:

  * llvm/utils/crosstool/create-snapshots.sh
  � creates tarballs for LLVM and LLVM-GCC from HEAD SVN or a specific
  revision of your choice
  * llvm/utils/crosstool/ARM/build-install-linux.sh
  � builds and installs a Linux/x86 -> Linux/ARM crosstool using the
  snapshots generated by the above script.� It also uses the
  CodeSourcery GCC-based cross toolchain to avoid having to rebuild
  cross-binutils and glibc, but if you don't have it, it'll tell you
  where to download it from.

  Note that HEAD revision of SVN doesn't work for me, but I listed the
  latest one I've tried that does, which is 70786.
  Let me know if this approach works for you.

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

-- 
Be Yourself @ mail.com!
Choose From 200+ Email Addresses
Get a Free Account at www.mail.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090614/0c550056/attachment.html>

From wesley at terpstra.ca  Sun Jun 14 05:59:12 2009
From: wesley at terpstra.ca (Wesley W. Terpstra)
Date: Sun, 14 Jun 2009 14:59:12 +0200
Subject: [LLVMdev] ML types in LLVM
In-Reply-To: <4A34614B.4010901@mxc.ca>
References: <162de7480906130354m430f9e17ndbf03b41592ab982@mail.gmail.com>
	<B4B325FE-9632-4767-85DD-896F7A8D5000@apple.com>
	<162de7480906131714s48a56b16v9464f8040ee61710@mail.gmail.com>
	<4A34614B.4010901@mxc.ca>
Message-ID: <162de7480906140559s487778a2q336af87f19727e97@mail.gmail.com>

On Sun, Jun 14, 2009 at 4:32 AM, Nick Lewycky<nicholas at mxc.ca> wrote:
> Wesley W. Terpstra wrote:
>> Is there absolutely no way to generate a new type? Not even an 'opaque' one?
> Each time you say "opaque" in a .ll (or call OpaqueType::get in the C++
> API) you get yourself a new distinct opaque type.

Ok. That's what I thought it did which is why I tried it in the first
place. I must have done something wrong. Thank you!

>> Also, I couldn't find a no-op instruction in LLVM. In some places it
>> would be convenient to say: '%x = %y'. For the moment I'm doing a
>> bitcast from the type back to itself, which is rather awkward.
>
> There is none, using a bitcast is the workaround. LLVM's optimizers will
> fix it up.

I'll keep doing what I'm doing then.


From wesley at terpstra.ca  Sun Jun 14 06:09:33 2009
From: wesley at terpstra.ca (Wesley W. Terpstra)
Date: Sun, 14 Jun 2009 15:09:33 +0200
Subject: [LLVMdev] ML types in LLVM
In-Reply-To: <877hzfqjvu.fsf@mid.deneb.enyo.de>
References: <162de7480906130354m430f9e17ndbf03b41592ab982@mail.gmail.com>
	<B4B325FE-9632-4767-85DD-896F7A8D5000@apple.com>
	<162de7480906131714s48a56b16v9464f8040ee61710@mail.gmail.com>
	<877hzfqjvu.fsf@mid.deneb.enyo.de>
Message-ID: <162de7480906140609y3c1f0584if03caa7bd993e43c@mail.gmail.com>

On Sun, Jun 14, 2009 at 10:50 AM, Florian Weimer<fw at deneb.enyo.de> wrote:
> Is this really a problem for MLton?  I think you only get less precise
> alias analysis, and that's it.

Correct. However, I want a fair comparison between LLVM performance
and the native x86 codegen. If I don't give LLVM the same information
the x86 codegen has, it's an unfair comparison.



From mawe at cse.ohio-state.edu  Sun Jun 14 06:18:42 2009
From: mawe at cse.ohio-state.edu (wenjing ma)
Date: Sun, 14 Jun 2009 09:18:42 -0400 (EDT)
Subject: [LLVMdev] Live range of variables
Message-ID: <Pine.GSO.4.40.0906140917320.13312-100000@kappa.cse.ohio-state.edu>

I wonder whether there is any analysis in LLVM that gets the live range of
variables. Is it in the optimization passes?



From baldrick at free.fr  Sun Jun 14 06:53:06 2009
From: baldrick at free.fr (Duncan Sands)
Date: Sun, 14 Jun 2009 15:53:06 +0200
Subject: [LLVMdev] ML types in LLVM
In-Reply-To: <162de7480906140609y3c1f0584if03caa7bd993e43c@mail.gmail.com>
References: <162de7480906130354m430f9e17ndbf03b41592ab982@mail.gmail.com>	<B4B325FE-9632-4767-85DD-896F7A8D5000@apple.com>	<162de7480906131714s48a56b16v9464f8040ee61710@mail.gmail.com>	<877hzfqjvu.fsf@mid.deneb.enyo.de>
	<162de7480906140609y3c1f0584if03caa7bd993e43c@mail.gmail.com>
Message-ID: <4A3500C2.7000602@free.fr>

Wesley W. Terpstra wrote:
> On Sun, Jun 14, 2009 at 10:50 AM, Florian Weimer<fw at deneb.enyo.de> wrote:
>> Is this really a problem for MLton?  I think you only get less precise
>> alias analysis, and that's it.
> 
> Correct. However, I want a fair comparison between LLVM performance
> and the native x86 codegen. If I don't give LLVM the same information
> the x86 codegen has, it's an unfair comparison.

I don't think alias analysis currently pays any attention to the
pointer type, so using i8* and bitcasting to the right types
shouldn't hurt.  I could be wrong though.

Ciao,

Duncan.


From aaronngray.lists at googlemail.com  Sun Jun 14 09:02:40 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Sun, 14 Jun 2009 17:02:40 +0100
Subject: [LLVMdev] ML types in LLVM
In-Reply-To: <162de7480906130354m430f9e17ndbf03b41592ab982@mail.gmail.com>
References: <162de7480906130354m430f9e17ndbf03b41592ab982@mail.gmail.com>
Message-ID: <9719867c0906140902q614e02a8l6dbef18db033727e@mail.gmail.com>

Does this help :-

struct TaggedUnionType {
  enum { Byte, Char, Int } Type;
  union {
    uint_8 b;
    char c;
    uint32_t i;
  };
};
int main( int argc, char *argv[])
{
    TaggedUnionType t;
    t.Type = Int;
    t.i = 0xAA55;
    switch( t.Type)
    {
    case Byte:
      {
        printf( "Byte = %0x2\n", t.b);
        break;
      }
    case Char:
      {
        printf( "Char = %c\n", t.c);
        break;
      }
    case Int:
      {
        printf( "Int = %0x8\n", t.i);
        break;
      }
    return 0;
}

Output from LLVM disassembler
; ModuleID = '/tmp/webcompile/_613_0.bc'
target datalayout =
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
target triple = "i386-pc-linux-gnu"
 %struct.TaggedUnionType = type { i32, %"struct.TaggedUnionType::._11" }
 %"struct.TaggedUnionType::._11" = type { i32 }
@.str = internal constant [13 x i8] c"Byte = %0x2\0A\00"  ; <[13 x i8]*>
[#uses=1]
@.str1 = internal constant [11 x i8] c"Char = %c\0A\00"  ; <[11 x i8]*>
[#uses=1]
@.str2 = internal constant [12 x i8] c"Int = %0x8\0A\00"  ; <[12 x i8]*>
[#uses=1]
define i32 @main(i32 %argc, i8** %argv) {
entry:
 %argc_addr = alloca i32  ; <i32*> [#uses=1]
 %argv_addr = alloca i8**  ; <i8***> [#uses=1]
 %retval = alloca i32  ; <i32*> [#uses=2]
 %t = alloca %struct.TaggedUnionType  ; <%struct.TaggedUnionType*> [#uses=6]
 %0 = alloca i32  ; <i32*> [#uses=2]
 %"alloca point" = bitcast i32 0 to i32  ; <i32> [#uses=0]
 store i32 %argc, i32* %argc_addr
 store i8** %argv, i8*** %argv_addr
 %1 = getelementptr %struct.TaggedUnionType* %t, i32 0, i32 0  ; <i32*>
[#uses=1]
 store i32 2, i32* %1, align 4
 %2 = getelementptr %struct.TaggedUnionType* %t, i32 0, i32 1  ;
<%"struct.TaggedUnionType::._11"*> [#uses=1]
 %3 = getelementptr %"struct.TaggedUnionType::._11"* %2, i32 0, i32 0  ;
<i32*> [#uses=1]
 store i32 43605, i32* %3, align 4
 %4 = getelementptr %struct.TaggedUnionType* %t, i32 0, i32 0  ; <i32*>
[#uses=1]
 %5 = load i32* %4, align 4  ; <i32> [#uses=1]
 switch i32 %5, label %bb3 [
  i32 0, label %bb
  i32 1, label %bb1
  i32 2, label %bb2
 ]
bb:  ; preds = %entry
 %6 = getelementptr %struct.TaggedUnionType* %t, i32 0, i32 1  ;
<%"struct.TaggedUnionType::._11"*> [#uses=1]
 %7 = getelementptr %"struct.TaggedUnionType::._11"* %6, i32 0, i32 0  ;
<i32*> [#uses=1]
 %8 = bitcast i32* %7 to i8*  ; <i8*> [#uses=1]
 %9 = load i8* %8, align 4  ; <i8> [#uses=1]
 %10 = zext i8 %9 to i32  ; <i32> [#uses=1]
 %11 = call i32 (i8*, ...)* @printf(i8* noalias getelementptr ([13 x i8]*
@.str, i32 0, i32 0), i32 %10)  ; <i32> [#uses=0]
 br label %bb3
bb1:  ; preds = %entry
 %12 = getelementptr %struct.TaggedUnionType* %t, i32 0, i32 1  ;
<%"struct.TaggedUnionType::._11"*> [#uses=1]
 %13 = getelementptr %"struct.TaggedUnionType::._11"* %12, i32 0, i32 0  ;
<i32*> [#uses=1]
 %14 = bitcast i32* %13 to i8*  ; <i8*> [#uses=1]
 %15 = load i8* %14, align 4  ; <i8> [#uses=1]
 %16 = sext i8 %15 to i32  ; <i32> [#uses=1]
 %17 = call i32 (i8*, ...)* @printf(i8* noalias getelementptr ([11 x i8]*
@.str1, i32 0, i32 0), i32 %16)  ; <i32> [#uses=0]
 br label %bb3
bb2:  ; preds = %entry
 %18 = getelementptr %struct.TaggedUnionType* %t, i32 0, i32 1  ;
<%"struct.TaggedUnionType::._11"*> [#uses=1]
 %19 = getelementptr %"struct.TaggedUnionType::._11"* %18, i32 0, i32 0  ;
<i32*> [#uses=1]
 %20 = load i32* %19, align 4  ; <i32> [#uses=1]
 %21 = call i32 (i8*, ...)* @printf(i8* noalias getelementptr ([12 x i8]*
@.str2, i32 0, i32 0), i32 %20)  ; <i32> [#uses=0]
 br label %bb3
bb3:  ; preds = %bb2, %bb1, %bb, %entry
 store i32 0, i32* %0, align 4
 %22 = load i32* %0, align 4  ; <i32> [#uses=1]
 store i32 %22, i32* %retval, align 4
 br label %return
return:  ; preds = %bb3
 %retval4 = load i32* %retval  ; <i32> [#uses=1]
 ret i32 %retval4
}
declare i32 @printf(i8* noalias, ...)

Use :-

    http://llvm.org/demo/index.cgi

To convert the code. Making sure optimization is turned off, its good
optimization !

The other approach is a C++ style inheritance and have a base class with a
tag in and sub types as inheriting classes.

Hope this helps,

Aaron







2009/6/13 Wesley W. Terpstra <wesley at terpstra.ca>

> Good afternoon!
>
> I'm trying to write an LLVM codegen for a Standard ML compiler
> (MLton). So far things seem to match up quite nicely, but I have hit
> two sticking points. I'm hoping LLVM experts might know how to handle
> these two cases better.
>
> 1: In ML we have some types that are actually one of several possible
> types. Expressed in C this might be thought of as a union. The codegen
> only ever accesses these 'union types' via pointer. Before actually
> indexing into the type, it always casts from the 'union pointer type'
> to a specific pointer type.
>
> As a concrete example. I have two types %a and %b. I want to express a
> third type %c that is either %a* or %b*. Later I'll cast the %c to
> either %a* or %b*.
>
> Currently I just represent %c as i8*. I assume that this can have
> consequences in terms of aliasing. I tried opaque*, but llvm-as didn't
> like that. Is there any way to better represent the type %c to LLVM?
>
> 2: In the ML heap we have objects that are garbage collected. Objects
> are preceded by a header that describes the object to the garbage
> collector. However, pointers to the objects point past the header and
> at the actual object. Sometimes, however, the program itself accesses
> the header. For example, to determine the length of an array (the
> length is in the header). For every type I output it like this:
>
> %opt_33 = { i32, %opt_45*, float }
>
> I could also create another type which includes the header something like:
> %opt_33_with_header = {i32, %opt_33 }
>
> Is there any way to express that a pointer is actually a pointer to an
> interior element of a type? Something like %opt_33_in_heap =
> %opt_33_with_header:1 ?
>
> Currently when I want to read the header of an %opt_33, I cast it to a
> i32* and then use getelementptr -1. Is there a better way?
> _______________________________________________
> 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.llvm.org/pipermail/llvm-dev/attachments/20090614/7afc43c6/attachment.html>

From rjmccall at apple.com  Sun Jun 14 12:33:59 2009
From: rjmccall at apple.com (John McCall)
Date: Sun, 14 Jun 2009 12:33:59 -0700
Subject: [LLVMdev] ML types in LLVM
In-Reply-To: <162de7480906131714s48a56b16v9464f8040ee61710@mail.gmail.com>
References: <162de7480906130354m430f9e17ndbf03b41592ab982@mail.gmail.com>
	<B4B325FE-9632-4767-85DD-896F7A8D5000@apple.com>
	<162de7480906131714s48a56b16v9464f8040ee61710@mail.gmail.com>
Message-ID: <ABD45882-09CB-4D39-A560-DB98F026435E@apple.com>

On Jun 13, 2009, at 5:14 PM, Wesley W. Terpstra wrote:
> On Sat, Jun 13, 2009 at 9:44 PM, John McCall<rjmccall at apple.com>  
> wrote:
>> Logically, what you want is a distinct LLVM type for every ML union  
>> type
>> and each of its constructors.  Unfortunately, LLVM does structural
>> uniquing of types, so that won't work.
>
> Is there absolutely no way to generate a new type? Not even an  
> 'opaque' one?

As mentioned, you can generate new opaque types, but obviously that
won't work for, say, distinguishing between separate constructors that  
are
structured identically.  If you're not planning to write any LLVM-level
language-specific optimizations, that probably doesn't matter at all.
On the other hand, you were talking about alias analysis, which  
generally
involves writing a pass to inject language-specific information.

>>  What you can do is abuse address
>> spaces, giving every distinct type its own address space and casting
>> back and forth between address spaces as necessary.
>
> The manual indicates that only addresses in space 0 can have GC
> intrinsics used on them.

More casts!  Although I'm curious why this limitation is in effect at  
all;
probably a consequence of some other overloaded use of address
spaces.

> Also I get the impression that this would be a pretty unsafe idea. ;)

Not particularly less safe than all the other unsafe casts you're  
planning
to use.

>> Is there any way to express that a pointer is actually a pointer to  
>> an
>> interior element of a type? Something like %opt_33_in_heap =
>> %opt_33_with_header:1 ?
>>
>> Something like an ungetelementptr?  No, sorry.  That would be a
>> pretty nice extension, though obviously unsound, of course.
>
> Well, ungetelementptr could be nice, but I was hoping for something
> even better: a way to refer to the whole object type (including the
> header) even though my pointer doesn't point to the start of the
> object. Ie: this is a pointer to 8 bytes past type X.

Okay.  You are right, there is no way to express this in the type  
system,
and that is very unlikely to change.

>> Personally, I would create a struct type (hereafter "HeaderType")  
>> for the
>> entire GC header;  when you want to access a header field, just  
>> cast the
>> base pointer to i8*, subtract the allocation size of HeaderType,  
>> cast the
>> result to HeaderType*, and getelementptr from there.
>
> That's what I'm doing right now; the HeaderType happens to be i32. ;)
> I am assuming that casting in and out of i8* will cost me in terms of
> the optimizations LLVM can apply..?

It would only really affect a type-based alias analysis, and there's no
cookie-cutter version of that;  you would need to write your own AA
pass, which could then easily recognize the pattern of accessing the
header.

> Also, I couldn't find a no-op instruction in LLVM. In some places it
> would be convenient to say: '%x = %y'. For the moment I'm doing a
> bitcast from the type back to itself, which is rather awkward.

The bitcast is a decent workaround, but the real question is why you  
need
a no-op at all;  if you're doing it to provide a hook for optimizer
information, a call is probably a better idea.

John.


From aaronngray.lists at googlemail.com  Sun Jun 14 16:50:03 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Mon, 15 Jun 2009 00:50:03 +0100
Subject: [LLVMdev] PIC
Message-ID: <211F30E6FD3D4205AF3F60B02D9C64AC@HPLAPTOP>

Could someone give me an overview of the PIC stuff if at all possible.

Many thanks,

Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090615/4defff02/attachment.html>

From mailinglists at MailNewsRSS.com  Sun Jun 14 18:09:03 2009
From: mailinglists at MailNewsRSS.com (Jason Todd Slack-Moehrle)
Date: Sun, 14 Jun 2009 18:09:03 -0700
Subject: [LLVMdev] Some understanding of LLVM vs gCC vs Intel C++ Compilers
Message-ID: <FAD2E372-2FC6-410E-9ECE-1AEAD896996D@MailNewsRSS.com>

Hi All,

I have spent a better part of my 32 years on this earth writing  
Solaris software and more recently leaving that and returning back to  
Mac OS.

I obviously know about GCC and the Intel C++ Compilers.

I am looking to have more freedom and flexibility along with producing  
better quality software.

How does LLVm fit in?

I know that it is a C/C++ Compiler, but how do I use it? Is it  
Makefile based?

Does it replace GCC?

Can one build full OS X applications with it? (What I mean is dont  
need to use XCode or anything if I dont want to)

I would totally appreciate advice!

Thanks,

-Jason


From zhangzhengjian at gmail.com  Sun Jun 14 18:36:15 2009
From: zhangzhengjian at gmail.com (zhengjian zhang)
Date: Mon, 15 Jun 2009 09:36:15 +0800
Subject: [LLVMdev] eh_sjlj_setjmp/ongjmp ?
Message-ID: <8e3538210906141836m2cd1452x8eab5d6f88aa147d@mail.gmail.com>

Hi,

    I have checkout  llvm from the  svn,    eh_sjlj_setjmp/longjmp
intrinsics  had beed added !
but  it seems  llvm-gcc  does't generate the  eh_sjlj_setjmp/longjmp
intrinsics now ?

best regards
zhangzw


From samuraileumas at yahoo.com  Sun Jun 14 18:46:20 2009
From: samuraileumas at yahoo.com (Samuel Crow)
Date: Sun, 14 Jun 2009 18:46:20 -0700 (PDT)
Subject: [LLVMdev] Some understanding of LLVM vs gCC vs Intel C++
	Compilers
In-Reply-To: <FAD2E372-2FC6-410E-9ECE-1AEAD896996D@MailNewsRSS.com>
References: <FAD2E372-2FC6-410E-9ECE-1AEAD896996D@MailNewsRSS.com>
Message-ID: <188062.59419.qm@web62005.mail.re1.yahoo.com>






----- Original Message ----
> From: Jason Todd Slack-Moehrle <mailinglists at mailnewsrss.com>
> To: llvmdev at cs.uiuc.edu
> Sent: Sunday, June 14, 2009 8:09:03 PM
> Subject: [LLVMdev] Some understanding of LLVM vs gCC vs Intel C++ Compilers
> 
> Hi All,

Hello Jason,

> I know that it is a C/C++ Compiler, but how do I use it? Is it  
> Makefile based?
> 

Wrong.  LLVM-GCC is a frontend for LLVM that converts C/C++ code into the intermediate representation that is LLVM.

> Does it replace GCC?
> 

It uses a special version of GCC currently to generate its bitcode from C/C++.  There is a GCC replacement called Clang that is coming up but not mature yet.

LLVM stands for Low-Level Virtual Machine.  It is an open-source, cross-architecture compiler infrastructure.  It runs on and generates code for MacOSX 10.4+ for both PPC and Intel, Windows XP+, Linux on several processor types, and others in the works.

With some effort, it is possible to write a compiler to generate bitcode that will run on any processor independently of the one it was written on.  It does not have a thick abstraction layer like .NET or Java, however.  For that extension you'll want to look into VMKit which is another implementation of Java and .NET using LLVM.  Anther compiler that is going to use the LLVM architecture is Google's Unladen Swallow project which aims to make the Python programming language execute 5 times faster.

I hope this answers some of you questions,

--Sam



      


From clattner at apple.com  Sun Jun 14 20:50:32 2009
From: clattner at apple.com (Chris Lattner)
Date: Sun, 14 Jun 2009 20:50:32 -0700
Subject: [LLVMdev] Some understanding of LLVM vs gCC vs Intel C++
	Compilers
In-Reply-To: <FAD2E372-2FC6-410E-9ECE-1AEAD896996D@MailNewsRSS.com>
References: <FAD2E372-2FC6-410E-9ECE-1AEAD896996D@MailNewsRSS.com>
Message-ID: <A3CE7459-3222-4E80-A696-B94E25BCE04F@apple.com>

On Jun 14, 2009, at 6:09 PM, Jason Todd Slack-Moehrle wrote:
> Hi All,

Hi Jason,

Sam's response is right on for general guidance, here is some mac- 
specific guidance.

> I have spent a better part of my 32 years on this earth writing
> Solaris software and more recently leaving that and returning back to
> Mac OS.
>
> I obviously know about GCC and the Intel C++ Compilers.
>
> I am looking to have more freedom and flexibility along with producing
> better quality software.
>
> How does LLVm fit in?

The llvm project provides two open source compilers, llvm-gcc and  
clang.  Clang is considered production quality on the mac for C and  
ObjC.  llvm-gcc on the mac supports c/objc/c++/objc++.  Apple  
productizes these and ships them with the Xcode installation.

> I know that it is a C/C++ Compiler, but how do I use it? Is it
> Makefile based?
>
> Does it replace GCC?

Both llvm-gcc and clang work as drop in replacements for GCC.  They  
take the same command line options etc, and are both quite usable on  
the command line.

> Can one build full OS X applications with it? (What I mean is dont
> need to use XCode or anything if I dont want to)

Yes, absolutely.

-Chris


From eli.friedman at gmail.com  Sun Jun 14 21:14:13 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Sun, 14 Jun 2009 21:14:13 -0700
Subject: [LLVMdev] eh_sjlj_setjmp/ongjmp ?
In-Reply-To: <8e3538210906141836m2cd1452x8eab5d6f88aa147d@mail.gmail.com>
References: <8e3538210906141836m2cd1452x8eab5d6f88aa147d@mail.gmail.com>
Message-ID: <f5aa3e9b0906142114t39aece25j9874b38d1dc54184@mail.gmail.com>

On Sun, Jun 14, 2009 at 6:36 PM, zhengjian
zhang<zhangzhengjian at gmail.com> wrote:
> Hi,
>
>    I have checkout  llvm from the  svn,    eh_sjlj_setjmp/longjmp
> intrinsics  had beed added !
> but  it seems  llvm-gcc  does't generate the  eh_sjlj_setjmp/longjmp
> intrinsics now ?

The implementation isn't finished (the only working CodeGen is for
eh_sjlj_setjmp on ARM), so there's no point to generating them.

-Eli



From mailinglists at MailNewsRSS.com  Sun Jun 14 21:17:48 2009
From: mailinglists at MailNewsRSS.com (Jason Todd Slack-Moehrle)
Date: Sun, 14 Jun 2009 21:17:48 -0700
Subject: [LLVMdev] Some understanding of LLVM vs gCC vs Intel C++
	Compilers
In-Reply-To: <A3CE7459-3222-4E80-A696-B94E25BCE04F@apple.com>
References: <FAD2E372-2FC6-410E-9ECE-1AEAD896996D@MailNewsRSS.com>
	<A3CE7459-3222-4E80-A696-B94E25BCE04F@apple.com>
Message-ID: <6F675FC4-66EA-46BF-93D5-F29B154492B0@MailNewsRSS.com>

Hi Chris,

Thanks for the response.

>> How does LLVm fit in?
>
> The llvm project provides two open source compilers, llvm-gcc and
> clang.  Clang is considered production quality on the mac for C and
> ObjC.  llvm-gcc on the mac supports c/objc/c++/objc++.  Apple
> productizes these and ships them with the Xcode installation.
>
>> I know that it is a C/C++ Compiler, but how do I use it? Is it
>> Makefile based?
>>
>> Does it replace GCC?
>
> Both llvm-gcc and clang work as drop in replacements for GCC.  They
> take the same command line options etc, and are both quite usable on
> the command line.

Can you provide advice on why Intel C++ compilers vs LLVM-GCC vs just  
normal GCC? Like benefits to one over the others? Pros and Cons, etc,  
etc...

Best,
-Jason



From erlv5241 at gmail.com  Sun Jun 14 21:20:38 2009
From: erlv5241 at gmail.com (erlv)
Date: Mon, 15 Jun 2009 12:20:38 +0800
Subject: [LLVMdev] Some understanding of LLVM vs gCC vs Intel C++
	Compilers
In-Reply-To: <188062.59419.qm@web62005.mail.re1.yahoo.com>
References: <FAD2E372-2FC6-410E-9ECE-1AEAD896996D@MailNewsRSS.com> 
	<188062.59419.qm@web62005.mail.re1.yahoo.com>
Message-ID: <2f7426020906142120l162a5c49k1558f476a533021e@mail.gmail.com>

     Thanks to Sam。
    As a fresh man on compiler, this mail helps me a lot :)

On Mon, Jun 15, 2009 at 9:46 AM, Samuel Crow<samuraileumas at yahoo.com> wrote:
>
>
>
>
>
> ----- Original Message ----
>> From: Jason Todd Slack-Moehrle <mailinglists at mailnewsrss.com>
>> To: llvmdev at cs.uiuc.edu
>> Sent: Sunday, June 14, 2009 8:09:03 PM
>> Subject: [LLVMdev] Some understanding of LLVM vs gCC vs Intel C++ Compilers
>>
>> Hi All,
>
> Hello Jason,
>
>> I know that it is a C/C++ Compiler, but how do I use it? Is it
>> Makefile based?
>>
>
> Wrong.  LLVM-GCC is a frontend for LLVM that converts C/C++ code into the intermediate representation that is LLVM.
>
>> Does it replace GCC?
>>
>
> It uses a special version of GCC currently to generate its bitcode from C/C++.  There is a GCC replacement called Clang that is coming up but not mature yet.
>
> LLVM stands for Low-Level Virtual Machine.  It is an open-source, cross-architecture compiler infrastructure.  It runs on and generates code for MacOSX 10.4+ for both PPC and Intel, Windows XP+, Linux on several processor types, and others in the works.
>
> With some effort, it is possible to write a compiler to generate bitcode that will run on any processor independently of the one it was written on.  It does not have a thick abstraction layer like .NET or Java, however.  For that extension you'll want to look into VMKit which is another implementation of Java and .NET using LLVM.  Anther compiler that is going to use the LLVM architecture is Google's Unladen Swallow project which aims to make the Python programming language execute 5 times faster.
>
> I hope this answers some of you questions,
>
> --Sam
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>



-- 
Hi,this is an email from Lincoin Ling.
Wish you every success in the future.

您好，这是来自Erlv的邮件。
祝您事事顺心，一生平安！



From anton at korobeynikov.info  Sun Jun 14 21:27:45 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Mon, 15 Jun 2009 08:27:45 +0400
Subject: [LLVMdev] PIC documentation ?
In-Reply-To: <8653927FD91A400AB077D2EF48F7132D@HPLAPTOP>
References: <8653927FD91A400AB077D2EF48F7132D@HPLAPTOP>
Message-ID: <b087fca00906142127n55bcaa7bi729be3d6c2e9ae56@mail.gmail.com>

Hello, Aaron

> Is there any overview or detailed socumentation on LLVM PIC ?
Did you mean Position Independent Code? If so - there is nothing
special here, LLVM just implements (when this is implemented) what is
defined in platform ABI.

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


From clattner at apple.com  Sun Jun 14 21:37:40 2009
From: clattner at apple.com (Chris Lattner)
Date: Sun, 14 Jun 2009 21:37:40 -0700
Subject: [LLVMdev] Some understanding of LLVM vs gCC vs Intel
	C++	Compilers
In-Reply-To: <6F675FC4-66EA-46BF-93D5-F29B154492B0@MailNewsRSS.com>
References: <FAD2E372-2FC6-410E-9ECE-1AEAD896996D@MailNewsRSS.com>
	<A3CE7459-3222-4E80-A696-B94E25BCE04F@apple.com>
	<6F675FC4-66EA-46BF-93D5-F29B154492B0@MailNewsRSS.com>
Message-ID: <79F90F65-2CD0-441C-BFCD-D2822C1544E8@apple.com>


On Jun 14, 2009, at 9:17 PM, Jason Todd Slack-Moehrle wrote:

>>
>> Both llvm-gcc and clang work as drop in replacements for GCC.  They
>> take the same command line options etc, and are both quite usable on
>> the command line.
>
> Can you provide advice on why Intel C++ compilers vs LLVM-GCC vs just
> normal GCC? Like benefits to one over the others? Pros and Cons, etc,
> etc...

Not really, I'm not very familiar with intel's C++ compiler.  One  
obvious advantage of llvm-gcc is that it's free :)

-Chris


From me22.ca at gmail.com  Sun Jun 14 23:32:21 2009
From: me22.ca at gmail.com (me22)
Date: Sun, 14 Jun 2009 23:32:21 -0700
Subject: [LLVMdev] Some understanding of LLVM vs gCC vs Intel C++
	Compilers
In-Reply-To: <6F675FC4-66EA-46BF-93D5-F29B154492B0@MailNewsRSS.com>
References: <FAD2E372-2FC6-410E-9ECE-1AEAD896996D@MailNewsRSS.com> 
	<A3CE7459-3222-4E80-A696-B94E25BCE04F@apple.com>
	<6F675FC4-66EA-46BF-93D5-F29B154492B0@MailNewsRSS.com>
Message-ID: <fa28b9250906142332p27914ab3hb90ae6e93781884@mail.gmail.com>

2009/6/14 Jason Todd Slack-Moehrle <mailinglists at mailnewsrss.com>:
>
> Can you provide advice on why Intel C++ compilers vs LLVM-GCC vs just
> normal GCC? Like benefits to one over the others? Pros and Cons, etc,
> etc...
>

My (possibly faultly) understanding is that intel's has good support
for numerics, presumably through auto-vectorization and such, but only
works for intel's architectures and is only excellent on intel chips.
llvm-gcc is a temporary thing until clang can compile llvm.  GCC is
for when you don't want to use the llvm infrastructure, and just want
something easy to grab from the package manager.

In general, anyways.
~ Scott


From sanjiv.gupta at microchip.com  Sun Jun 14 23:30:14 2009
From: sanjiv.gupta at microchip.com (Sanjiv Gupta)
Date: Mon, 15 Jun 2009 12:00:14 +0530
Subject: [LLVMdev] llvmc for PIC16
In-Reply-To: <loom.20090607T070933-452@post.gmane.org>
References: <4A2633E9.4070207@microchip.com><loom.20090604T142600-116@post.gmane.org><4A28C062.9060307@microchip.com>
	<loom.20090607T070933-452@post.gmane.org>
Message-ID: <4A35EA76.7090602@microchip.com>

Mikhail Glushenkov wrote:
>
> Hi Sanjiv,
>
> Sanjiv Gupta <sanjiv.gupta <at> microchip.com> writes:
>
> > The salient features that we want to have in the driver are:
> > [...]
>
> As promised, I've implemented a basic compiler driver for the
> PIC16 toolchain. It's under tools/llvmc/examples/mcc16.
>
Hi Mikhail,
How do you build mcc16 executable?
There are so many confusing things there: driver, plugins, example, 
Skelton etc.
The LLVMC-Tutorial doesn't clearly talk about them. Your help is 
appreciated.

Thanks,
Sanjiv
>
> Some examples illustrating the features you requested: 
>
> > 2. If the user has specified to generate the final executable, then
> > llvm-ld should run on all the .bc files generated by clang and create a
> > single optimized .bc file for further tools.
>
> $ mcc16 -dry-run foo.c bar.c
> clang-cc foo.c -o /tmp/llvm_6ibgr9/foo.bc
> clang-cc bar.c -o /tmp/llvm_6ibgr9/bar.bc
> llvm-ld /tmp/llvm_6ibgr9/foo.bc /tmp/llvm_6ibgr9/bar.bc \
>     -o /tmp/llvm_6ibgr9/tmp.bc
> llc -f /tmp/llvm_6ibgr9/tmp.bc -o /tmp/llvm_6ibgr9/tmp.s
> native-as /tmp/llvm_6ibgr9/tmp.s -o /tmp/llvm_6ibgr9/tmp.o
> native-ld /tmp/llvm_6ibgr9/tmp.o -o a.out
>
> > 3. -Wo <options> - pass optimizations to the llvm-ld
> > 4. mcc16 -Wl <options> - pass options to native linker.
> > 5. mcc16 -Wa <options> - pass options to native assembler.
>
> $ mcc16 -dry-run -Wo,-opt1 -Wllc,-opt2 -Wa,-opt3 -Wl,-opt4 foo.c
> clang-cc foo.c -o /tmp/llvm_92HLCj/foo.bc
> llvm-ld -opt1 /tmp/llvm_92HLCj/foo.bc -o /tmp/llvm_92HLCj/tmp.bc
> llc -opt2 -f /tmp/llvm_92HLCj/tmp.bc -o /tmp/llvm_92HLCj/tmp.s
> native-as -opt3 /tmp/llvm_92HLCj/tmp.s -o /tmp/llvm_92HLCj/tmp.o
> native-ld -opt4 /tmp/llvm_92HLCj/tmp.o -o a.out
>
> > $ mcc16 -S foo.c
>
> $ mcc16 -dry-run -S foo.c
> clang-cc foo.c -o /tmp/llvm_0uiDCR/foo.bc
> llvm-ld /tmp/llvm_0uiDCR/foo.bc -o /tmp/llvm_0uiDCR/foo.bc
> llc -f /tmp/llvm_0uiDCR/foo.bc -o foo.s
>
> > $ mcc16 -S foo.c bar.c
>
> $ mcc16 -dry-run -S foo.c bar.c
> clang-cc foo.c -o /tmp/llvm_1zAqik/foo.bc
> llvm-ld /tmp/llvm_1zAqik/foo.bc -o /tmp/llvm_1zAqik/foo.bc
> llc -f /tmp/llvm_1zAqik/foo.bc -o foo.s
> clang-cc bar.c -o /tmp/llvm_1zAqik/bar.bc
> llvm-ld /tmp/llvm_1zAqik/bar.bc -o /tmp/llvm_1zAqik/bar.bc
> llc -f /tmp/llvm_1zAqik/bar.bc -o bar.s
>
> > ** Use of -g causes llvm-ld to run with -disable-opt
> > $ mcc16 -S -g foo.c
>
> $ mcc16 -dry-run -S -g foo.c  
> clang-cc foo.c -o /tmp/llvm_oQFmVn/foo.bc
> llvm-ld -disable-opt /tmp/llvm_oQFmVn/foo.bc -o /tmp/llvm_oQFmVn/foo.bc
> llc -f /tmp/llvm_oQFmVn/foo.bc -o foo.s
>
> > ** -I is passed to clang-cc, -pre-RA-sched=list-burr to llc.
> > $ mcc16 -S -g -I ../include -pre-RA-sched=list-burr foo.c
>
> $ mcc16 -dry-run -S -g -I ../include -pre-RA-sched=list-burr foo.c
> clang-cc -I ../include foo.c -o /tmp/llvm_5VxNFQ/foo.bc
> llvm-ld -disable-opt /tmp/llvm_5VxNFQ/foo.bc -o /tmp/llvm_5VxNFQ/foo.bc
> llc -pre-RA-sched list-burr -f /tmp/llvm_5VxNFQ/foo.bc -o foo.s
>
> This should be enough to get you started.
>
> I'm always happy to answer any further questions you may have. If
> you want to e-mail me privately, please use the.dead.shall.rise
> <at_sign> gmail dot com for now (our provider problems weren't
> resolved yet).
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>



From sanjiv.gupta at microchip.com  Sun Jun 14 23:55:32 2009
From: sanjiv.gupta at microchip.com (Sanjiv Gupta)
Date: Mon, 15 Jun 2009 12:25:32 +0530
Subject: [LLVMdev] llvmc for PIC16
In-Reply-To: <4A35EA76.7090602@microchip.com>
References: <4A2633E9.4070207@microchip.com><loom.20090604T142600-116@post.gmane.org><4A28C062.9060307@microchip.com>
	<loom.20090607T070933-452@post.gmane.org>
	<4A35EA76.7090602@microchip.com>
Message-ID: <4A35F064.4080505@microchip.com>

I think the correct command line is
$ make LLVMC_BUILTIN_PLUGINS=MyPlugin LLVMC_BASED_DRIVER_NAME=mydriver

rather than
$ make BUILTIN_PLUGINS=MyPlugin DRIVER_NAME=mydriver
(I found the later one in LLVMC-Reference)

- Sanjiv

Sanjiv Gupta wrote:
> Mikhail Glushenkov wrote:
>>
>> Hi Sanjiv,
>>
>> Sanjiv Gupta <sanjiv.gupta <at> microchip.com> writes:
>>
>> > The salient features that we want to have in the driver are:
>> > [...]
>>
>> As promised, I've implemented a basic compiler driver for the
>> PIC16 toolchain. It's under tools/llvmc/examples/mcc16.
>>
> Hi Mikhail,
> How do you build mcc16 executable?
> There are so many confusing things there: driver, plugins, example, 
> Skelton etc.
> The LLVMC-Tutorial doesn't clearly talk about them. Your help is 
> appreciated.
>
> Thanks,
> Sanjiv
>>
>> Some examples illustrating the features you requested:
>> > 2. If the user has specified to generate the final executable, then
>> > llvm-ld should run on all the .bc files generated by clang and 
>> create a
>> > single optimized .bc file for further tools.
>>
>> $ mcc16 -dry-run foo.c bar.c
>> clang-cc foo.c -o /tmp/llvm_6ibgr9/foo.bc
>> clang-cc bar.c -o /tmp/llvm_6ibgr9/bar.bc
>> llvm-ld /tmp/llvm_6ibgr9/foo.bc /tmp/llvm_6ibgr9/bar.bc \
>>     -o /tmp/llvm_6ibgr9/tmp.bc
>> llc -f /tmp/llvm_6ibgr9/tmp.bc -o /tmp/llvm_6ibgr9/tmp.s
>> native-as /tmp/llvm_6ibgr9/tmp.s -o /tmp/llvm_6ibgr9/tmp.o
>> native-ld /tmp/llvm_6ibgr9/tmp.o -o a.out
>>
>> > 3. -Wo <options> - pass optimizations to the llvm-ld
>> > 4. mcc16 -Wl <options> - pass options to native linker.
>> > 5. mcc16 -Wa <options> - pass options to native assembler.
>>
>> $ mcc16 -dry-run -Wo,-opt1 -Wllc,-opt2 -Wa,-opt3 -Wl,-opt4 foo.c
>> clang-cc foo.c -o /tmp/llvm_92HLCj/foo.bc
>> llvm-ld -opt1 /tmp/llvm_92HLCj/foo.bc -o /tmp/llvm_92HLCj/tmp.bc
>> llc -opt2 -f /tmp/llvm_92HLCj/tmp.bc -o /tmp/llvm_92HLCj/tmp.s
>> native-as -opt3 /tmp/llvm_92HLCj/tmp.s -o /tmp/llvm_92HLCj/tmp.o
>> native-ld -opt4 /tmp/llvm_92HLCj/tmp.o -o a.out
>>
>> > $ mcc16 -S foo.c
>>
>> $ mcc16 -dry-run -S foo.c
>> clang-cc foo.c -o /tmp/llvm_0uiDCR/foo.bc
>> llvm-ld /tmp/llvm_0uiDCR/foo.bc -o /tmp/llvm_0uiDCR/foo.bc
>> llc -f /tmp/llvm_0uiDCR/foo.bc -o foo.s
>>
>> > $ mcc16 -S foo.c bar.c
>>
>> $ mcc16 -dry-run -S foo.c bar.c
>> clang-cc foo.c -o /tmp/llvm_1zAqik/foo.bc
>> llvm-ld /tmp/llvm_1zAqik/foo.bc -o /tmp/llvm_1zAqik/foo.bc
>> llc -f /tmp/llvm_1zAqik/foo.bc -o foo.s
>> clang-cc bar.c -o /tmp/llvm_1zAqik/bar.bc
>> llvm-ld /tmp/llvm_1zAqik/bar.bc -o /tmp/llvm_1zAqik/bar.bc
>> llc -f /tmp/llvm_1zAqik/bar.bc -o bar.s
>>
>> > ** Use of -g causes llvm-ld to run with -disable-opt
>> > $ mcc16 -S -g foo.c
>>
>> $ mcc16 -dry-run -S -g foo.c  clang-cc foo.c -o /tmp/llvm_oQFmVn/foo.bc
>> llvm-ld -disable-opt /tmp/llvm_oQFmVn/foo.bc -o /tmp/llvm_oQFmVn/foo.bc
>> llc -f /tmp/llvm_oQFmVn/foo.bc -o foo.s
>>
>> > ** -I is passed to clang-cc, -pre-RA-sched=list-burr to llc.
>> > $ mcc16 -S -g -I ../include -pre-RA-sched=list-burr foo.c
>>
>> $ mcc16 -dry-run -S -g -I ../include -pre-RA-sched=list-burr foo.c
>> clang-cc -I ../include foo.c -o /tmp/llvm_5VxNFQ/foo.bc
>> llvm-ld -disable-opt /tmp/llvm_5VxNFQ/foo.bc -o /tmp/llvm_5VxNFQ/foo.bc
>> llc -pre-RA-sched list-burr -f /tmp/llvm_5VxNFQ/foo.bc -o foo.s
>>
>> This should be enough to get you started.
>>
>> I'm always happy to answer any further questions you may have. If
>> you want to e-mail me privately, please use the.dead.shall.rise
>> <at_sign> gmail dot com for now (our provider problems weren't
>> resolved yet).
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
>



From the.dead.shall.rise at gmail.com  Mon Jun 15 03:48:10 2009
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Mon, 15 Jun 2009 12:48:10 +0200
Subject: [LLVMdev] llvmc for PIC16
In-Reply-To: <4A35EA76.7090602@microchip.com>
References: <4A2633E9.4070207@microchip.com>
	<loom.20090604T142600-116@post.gmane.org>
	<4A28C062.9060307@microchip.com>
	<loom.20090607T070933-452@post.gmane.org>
	<4A35EA76.7090602@microchip.com>
Message-ID: <3cb898890906150348l2e0d4095seb54de38f95e69f9@mail.gmail.com>

Hi Sanjiv,

2009/6/15 Sanjiv Gupta <sanjiv.gupta at microchip.com>:
> Hi Mikhail,
> How do you build mcc16 executable?

This should work:

$ cd $LLVM_DIR/tools/llvmc/examples/mcc16
$ make

If you're building from some other dir, you'll need to update
mcc16/Makefile, so it knows where Makefile.common is located.

> There are so many confusing things there: driver, plugins, example, Skelton
> etc.
> The LLVMC-Tutorial doesn't clearly talk about them.

Yes, I know, the documentation doesn't talk about creating standalone
drivers. Sorry for that, I was planning to update it for ages...
For now, please look at examples/Skeleton, which is a standalone
driver skeleton, on which the mcc16 driver is based.

> I think the correct command line is
> $ make LLVMC_BUILTIN_PLUGINS=MyPlugin LLVMC_BASED_DRIVER_NAME=mydriver
>
> rather than
> $ make BUILTIN_PLUGINS=MyPlugin DRIVER_NAME=mydriver
> (I found the later one in LLVMC-Reference)

This section is about building the "main" llvmc driver and its plugins.
Creation of standalone drivers is not described in the docs yet (it
was added relatively recently).

-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments


From Olaf.Krzikalla at tu-dresden.de  Mon Jun 15 04:33:19 2009
From: Olaf.Krzikalla at tu-dresden.de (Olaf Krzikalla)
Date: Mon, 15 Jun 2009 13:33:19 +0200
Subject: [LLVMdev] Some df_iterator and po_iterator issues
Message-ID: <4A36317F.4040006@tu-dresden.de>

Hi @llvm,

below is a copy of a message I sent to clang a hour before. I guess it's 
more appropriate here.

--snip--

While trying to eleminate as much std::tr1::function as possible I 
stumbled over a design flaw in llvm::df_iterator.
Consider the following code:

void for_all_stmts(Stmt* S, const std::tr1::function<void(Stmt*)>& fn)
{
  if (S)
  {
    fn(S);
    for (Stmt::child_iterator i = S->child_begin(), e = S->child_end(); 
i != e; ++i)
    {
      for_all_stmts(*i, fn);
    }
  }
}

In a first step I want to replace this with:

void for_all_stmts(Stmt* S, const std::tr1::function<void(Stmt*)>& fn)
{
  for (llvm::df_iterator<Stmt*> i = llvm::df_begin(S), e = 
llvm::df_end(S); i != e; ++i)
  {
    if (*i)  fn(*i);
  }
}

However if fn replaces childrens of a just processed statement (which 
happens a lot), the iteration may crash. Looking at df_iterator reveals 
the reason: the first child of a particular statement is stored too 
early for this kind of usage. IMHO this could be fixed by delaying the 
computation of the first child until it's needed (that is in the 
preincrement operator). The only open question would be: how do we mark 
the children iterator invalid before its first use.

--snip--

I added two patches to this mail. The first one (dfi) is a proposal 
fixing the problem described in the cut-out above.
The second one (poi) have to be applied anyway, as it fixes a compile 
bug rendering po_ext_iterator currently unusable.
However this second issued occured as part of another problem: a child 
Stmt of a Stmt in a clang AST can be 0 (e.g. in for(;;)).
I could work around it by providing po_ext_iterator an external set of 
visited nodes and just inserted 0 beforehand. However I'm quite sure it 
would be a better idea to catch the 0 case in po_iterator and 
df_iterator at all. Otherwise using these classes become tedious very 
quickly.

Best
Olaf Krzikalla

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dfi.patch
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090615/36dd77a4/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: poi.patch
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090615/36dd77a4/attachment-0001.ksh>

From wesley at terpstra.ca  Mon Jun 15 06:05:03 2009
From: wesley at terpstra.ca (Wesley W. Terpstra)
Date: Mon, 15 Jun 2009 15:05:03 +0200
Subject: [LLVMdev] Stack swapping
Message-ID: <162de7480906150605l44a594f5i5d5026e9d4b0fb73@mail.gmail.com>

Thanks to help in a previous thread, I now have a working LLVM codegen
for the MLton compiler. Currently the stack is managed explicitly on
the heap. This way the LLVM codegen re-uses the runtime layout of the
other codegens, simplifying the initial porting effort.

In the next phase I plan to switch to using LLVM to manage the stack,
but there is a sticking point: MLton switches stacks. It does this on
calls to C (which use the primordial C stack) and also between
application-level threads. ML stacks automatically expand when a limit
check triggers garbage collection. I understand that getting this to
work will require some non-portable glue on my part.

I have a number of ideas on how to get this to work, but also assume
that MLton isn't the first project which swaps stacks. What's the
established best practice for managing multiple stacks under LLVM?


From saliari2 at uiuc.edu  Mon Jun 15 02:41:11 2009
From: saliari2 at uiuc.edu (Saman Aliari Zonouz)
Date: Mon, 15 Jun 2009 11:41:11 +0200
Subject: [LLVMdev] VmKit Question.
Message-ID: <797a621f0906150241k530554afuedbfe0aa9938a339@mail.gmail.com>

Hi,

I compiled VmKit and got it running, but do not know how it is possible to
emit llvm-bitcode fram .java code. Would you please help me?

Thanks,
::Saman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090615/79240d35/attachment.html>

From victor.zverovich at googlemail.com  Mon Jun 15 02:35:27 2009
From: victor.zverovich at googlemail.com (Victor Zverovich)
Date: Mon, 15 Jun 2009 10:35:27 +0100
Subject: [LLVMdev] runtime library for jitted code
Message-ID: <a88d534c0906150235w6f0e3ce3i4302f4eeae6b03d0@mail.gmail.com>

Dear All,
I am considering a possibility of using LLVM JIT for an algebraic modelling
language. I have already done some prototyping following the Kaleidoscope
tutorial and currently thinking of how to connect the jitted code to a
runtime library (for this language) which I would like to code in C++. If it
was *NIX I would use g++ possibly with '-rdynamic' option as suggested in
the tutorial to resolve required functions at runtime. However it is not an
option, I am stuck to Windows and Visual C++. One possibility that I have
found is to create llvm::Function objects and use
ExecutionEngine::addGlobalMapping to map them to the implementations. This
works fine but is quite labour-consuming since every library function
required used in jitted code needs to be mapped. Does anyone know a better
way?

Thanks,
Victor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090615/a82ac575/attachment.html>

From anton at korobeynikov.info  Mon Jun 15 06:52:43 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Mon, 15 Jun 2009 17:52:43 +0400
Subject: [LLVMdev] runtime library for jitted code
In-Reply-To: <a88d534c0906150235w6f0e3ce3i4302f4eeae6b03d0@mail.gmail.com>
References: <a88d534c0906150235w6f0e3ce3i4302f4eeae6b03d0@mail.gmail.com>
Message-ID: <b087fca00906150652m6d836457r65f31a06f09cdef8@mail.gmail.com>

Hello, Victor

> found is to create llvm::Function objects and use
> ExecutionEngine::addGlobalMapping to map them to the implementations. This
> works fine but is quite labour-consuming since every library function
> required used in jitted code needs to be mapped. Does anyone know a better
> way?
Theoretically you should be able to load the .dll into address space
of the application, "register" it and stuff should magically work. I
am not sure whether this functionality obtained much care recently, so
some bugfixing might be needed.

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


From sanjiv.gupta at microchip.com  Mon Jun 15 07:11:47 2009
From: sanjiv.gupta at microchip.com (Sanjiv Gupta)
Date: Mon, 15 Jun 2009 19:41:47 +0530
Subject: [LLVMdev] llvmc for PIC16
In-Reply-To: <3cb898890906150348l2e0d4095seb54de38f95e69f9@mail.gmail.com>
References: <4A2633E9.4070207@microchip.com>	
	<loom.20090604T142600-116@post.gmane.org>	
	<4A28C062.9060307@microchip.com>	
	<loom.20090607T070933-452@post.gmane.org>	
	<4A35EA76.7090602@microchip.com>
	<3cb898890906150348l2e0d4095seb54de38f95e69f9@mail.gmail.com>
Message-ID: <4A3656A3.1050403@microchip.com>

Mikhail Glushenkov wrote:
> Hi Sanjiv,
>
> 2009/6/15 Sanjiv Gupta <sanjiv.gupta at microchip.com>:
>   
>> Hi Mikhail,
>> How do you build mcc16 executable?
>>     
>
> This should work:
>
> $ cd $LLVM_DIR/tools/llvmc/examples/mcc16
> $ make
>
>   
I configure llvm into a separate directory from source.
When I do the steps you mentioned in the source directory, this is what 
I get.

[i00171 at rhino mcc16]$ make
../../../../Makefile.common:61: ../../../../Makefile.config: No such 
file or directory
../../../../Makefile.common:69: /Makefile.rules: No such file or directory
make: *** No rule to make target `/Makefile.rules'.  Stop.

Ditto for the "Simple" plugin.

[i00171 at rhino mcc16]$ cd ../Simple/


../../../../Makefile.common:61: ../../../../Makefile.config: No such 
file or directory
../../../../Makefile.common:69: /Makefile.rules: No such file or directory
make: *** No rule to make target `/Makefile.rules'.  Stop.
[i00171 at rhino Simple]$


I copied the "Simple" plugin to the configured directory

$ cd objs/tools/llvmc/plugins
$ cp -rf $LLVM_SRC/tools/llvmc/example/Simple MyPlugin

Changed the plugin name in the Makefile from "Simple" to "MyPlugin", and 
moved "Simple.td" to "MyPlugin.td"

$ make LLVMC_BUILTIN_PLUGINS=MyPlugin LLVMC_BASED_DRIVER_NAME=mydriver

That created "mydriver" executable for me.

- Sanjiv
> If you're building from some other dir, you'll need to update
> mcc16/Makefile, so it knows where Makefile.common is located.
>
>   
>> There are so many confusing things there: driver, plugins, example, Skelton
>> etc.
>> The LLVMC-Tutorial doesn't clearly talk about them.
>>     
>
> Yes, I know, the documentation doesn't talk about creating standalone
> drivers. Sorry for that, I was planning to update it for ages...
> For now, please look at examples/Skeleton, which is a standalone
> driver skeleton, on which the mcc16 driver is based.
>
>   
>> I think the correct command line is
>> $ make LLVMC_BUILTIN_PLUGINS=MyPlugin LLVMC_BASED_DRIVER_NAME=mydriver
>>
>> rather than
>> $ make BUILTIN_PLUGINS=MyPlugin DRIVER_NAME=mydriver
>> (I found the later one in LLVMC-Reference)
>>     
>
> This section is about building the "main" llvmc driver and its plugins.
> Creation of standalone drivers is not described in the docs yet (it
> was added relatively recently).
>
>   



From the.dead.shall.rise at gmail.com  Mon Jun 15 07:30:00 2009
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Mon, 15 Jun 2009 16:30:00 +0200
Subject: [LLVMdev] llvmc for PIC16
In-Reply-To: <4A3656A3.1050403@microchip.com>
References: <4A2633E9.4070207@microchip.com>
	<loom.20090604T142600-116@post.gmane.org>
	<4A28C062.9060307@microchip.com>
	<loom.20090607T070933-452@post.gmane.org>
	<4A35EA76.7090602@microchip.com>
	<3cb898890906150348l2e0d4095seb54de38f95e69f9@mail.gmail.com>
	<4A3656A3.1050403@microchip.com>
Message-ID: <3cb898890906150730k534167dfxf59677e966477220@mail.gmail.com>

Hi Sanjiv,

2009/6/15 Sanjiv Gupta <sanjiv.gupta at microchip.com>:
> I configure llvm into a separate directory from source.
> When I do the steps you mentioned in the source directory, this is what I
> get.

In that case, copy $LLVM_DIR/tools/llvmc/example/mcc16/Makefile to
$LLVM_OBJ_DIR/tools/llvmc/example/mcc16/Makefile and build from that
directory.


From Dr.Graef at t-online.de  Mon Jun 15 07:39:49 2009
From: Dr.Graef at t-online.de (Albert Graef)
Date: Mon, 15 Jun 2009 16:39:49 +0200
Subject: [LLVMdev] runtime library for jitted code
In-Reply-To: <a88d534c0906150235w6f0e3ce3i4302f4eeae6b03d0@mail.gmail.com>
References: <a88d534c0906150235w6f0e3ce3i4302f4eeae6b03d0@mail.gmail.com>
Message-ID: <4A365D35.3040005@t-online.de>

Victor Zverovich wrote:
> I am considering a possibility of using LLVM JIT for an algebraic
> modelling language. I have already done some prototyping following the
> Kaleidoscope tutorial and currently thinking of how to connect the
> jitted code to a runtime library (for this language) which I would like
> to code in C++. If it was *NIX I would use g++ possibly with '-rdynamic'
> option as suggested in the tutorial to resolve required functions at
> runtime. However it is not an option, I am stuck to Windows and Visual
> C++.

Well, backlinking doesn't work on Windows, but you can create a dll for
your runtime and use LLVM's dynamic library interface to load that dll.
I'm doing it that way in my project (http://pure-lang.googlecode.com/,
search for 'sys::DynamicLibrary::' in interpreter.cc) and it works fine
on Windows.

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de
WWW:    http://www.musikinformatik.uni-mainz.de/ag


From nicolas.geoffray at lip6.fr  Mon Jun 15 07:47:29 2009
From: nicolas.geoffray at lip6.fr (Nicolas Geoffray)
Date: Mon, 15 Jun 2009 16:47:29 +0200
Subject: [LLVMdev] VmKit Question.
In-Reply-To: <797a621f0906150241k530554afuedbfe0aa9938a339@mail.gmail.com>
References: <797a621f0906150241k530554afuedbfe0aa9938a339@mail.gmail.com>
Message-ID: <4A365F01.6030502@lip6.fr>

Hi Saman,

The Release/bin/vmjc tool is the .class --> .bc compiler. It will 
compile .class files and .jar files to .bc files.

If you want to generate an executable with this .bc file, the process is 
more difficult. First you need to go to the tools/vmjc/libvmjc directory 
and type:
make ENABLE_OPTIMIZED=1

This should create a Release/lib/libvmjc.so file (assuming you're on 
Linux/x86, I'm having troubles with other archs), which contains the 
base classes (ie rt.jar) native representation (whose abi is vmkit 
specific). Now, to generate an executable, here's what you should do:

1) set LD_LIBRARY_PATH to the path containing the libvmjc.so
2) set PATH to contain the llvm binaries and the vmkit binaries
3) Use llcj with the same command line arguments than gcj, e.g: llcj 
--main=Test -O3 -o Test Test.class

This will be more documented at some point on the vmkit website, but 
with this info, you should be all set! And don't hesitate to ask if 
you're having trouble setting the compiler up.

Cheers,
Nicolas


Saman Aliari Zonouz wrote:
> Hi,
>
> I compiled VmKit and got it running, but do not know how it is 
> possible to emit llvm-bitcode fram .java code. Would you please help me?
>
> Thanks,
> ::Saman
> ------------------------------------------------------------------------
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   



From st at invia.fr  Mon Jun 15 07:59:42 2009
From: st at invia.fr (Sylvere Teissier)
Date: Mon, 15 Jun 2009 16:59:42 +0200
Subject: [LLVMdev] llvmc for PIC16
In-Reply-To: <4A3656A3.1050403@microchip.com>
References: <4A2633E9.4070207@microchip.com>
	<loom.20090604T142600-116@post.gmane.org>
	<4A28C062.9060307@microchip.com>
	<loom.20090607T070933-452@post.gmane.org>
	<4A35EA76.7090602@microchip.com>
	<3cb898890906150348l2e0d4095seb54de38f95e69f9@mail.gmail.com>
	<4A3656A3.1050403@microchip.com>
Message-ID: <1245077982.25082.3.camel@vostro-1510.invia>

There is another way for building mcc16 in tree indepandent of sources

Change   DIRS = plugins driver 
to       DIRS = plugins driverexample/mcc16

in tools/llmc/Makefile works for me

mcc16 is then generated directly from the llvm main makefile.



From ofv at wanadoo.es  Mon Jun 15 08:48:30 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Mon, 15 Jun 2009 17:48:30 +0200
Subject: [LLVMdev] runtime library for jitted code
References: <a88d534c0906150235w6f0e3ce3i4302f4eeae6b03d0@mail.gmail.com>
	<4A365D35.3040005@t-online.de>
Message-ID: <87ski1cxbl.fsf@telefonica.net>

Albert Graef <Dr.Graef at t-online.de> writes:

> Victor Zverovich wrote:
>> I am considering a possibility of using LLVM JIT for an algebraic
>> modelling language. I have already done some prototyping following the
>> Kaleidoscope tutorial and currently thinking of how to connect the
>> jitted code to a runtime library (for this language) which I would like
>> to code in C++. If it was *NIX I would use g++ possibly with '-rdynamic'
>> option as suggested in the tutorial to resolve required functions at
>> runtime. However it is not an option, I am stuck to Windows and Visual
>> C++.
>
> Well, backlinking doesn't work on Windows, but you can create a dll for
> your runtime and use LLVM's dynamic library interface to load that dll.
> I'm doing it that way in my project (http://pure-lang.googlecode.com/,
> search for 'sys::DynamicLibrary::' in interpreter.cc) and it works fine
> on Windows.

The OP says that he wants to link to a dll coded in C++. Isn't name
mangling the main problem here?

-- 
Óscar



From brukman at gmail.com  Mon Jun 15 09:41:17 2009
From: brukman at gmail.com (Misha Brukman)
Date: Mon, 15 Jun 2009 12:41:17 -0400
Subject: [LLVMdev] CROSS COMPILING LLVM
In-Reply-To: <20090614111911.EC16A1CE833@ws1-6.us4.outblaze.com>
References: <20090614111911.EC16A1CE833@ws1-6.us4.outblaze.com>
Message-ID: <f88b89a50906150941k7970b49eo6e5c3ae9832bb75d@mail.gmail.com>

2009/6/14 hannibal hannibal <hannibal_08 at mail.com>

>  I was able to use your scripts to build  llvm and llvm-gcc successfully.
> But when i try to link to llvm libraries i get the following :
>
> .........................
> ..........................
> /arm-2007q3/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.1/../../../../arm-none-linux-gnueabi/bin/ld:
> /arm-llvm/llvm-project/i686-pc-linux-gnu/arm-none-linux-gnueabi/llvm/lib/LLVMXCore.o:
> Relocations in generic ELF (EM: 3)
> /arm-llvm/llvm-project/i686-pc-linux-gnu/arm-none-linux-gnueabi/llvm/lib/LLVMXCore.o:
> could not read symbols: File in wrong format
>

What are you trying to do, exactly?  If you're trying to create an ARM
executable which uses LLVM libraries, note that you'd have to also
cross-compile LLVM first, using your new cross-compiler.  Otherwise, you're
trying to link ARM object files with x86_64 LLVM libraries, which aren't
compatible.

Note that I'm just guessing -- it's really hard to tell what's wrong without
complete information, e.g. exact command lines, your host machine, your
target machine, etc.

Misha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090615/d8ae7786/attachment.html>

From wesley at terpstra.ca  Mon Jun 15 09:46:18 2009
From: wesley at terpstra.ca (Wesley W. Terpstra)
Date: Mon, 15 Jun 2009 18:46:18 +0200
Subject: [LLVMdev] unwind/invoke design
Message-ID: <162de7480906150946h549a0463k164017cb85c85ad0@mail.gmail.com>

The documentation of unwind/invoke is quite clear and does exactly
what I need: unwinding the stack. I don't need it to carry an object
back. I don't need it to figure out what the type of the object is or
what catch() blocks it matches. I just need it to unwind the stack.
The rest is my job as a part of the runtime. Unfortunately, I have
learned that while this works with the bytecode evaluator, it doesn't
work with the JIT or native codegen [1].

There seems to have been discussion about making unwind/invoke
inter-operate with native c++ exceptions, and this complexity was
cited as being the reason it was too complex to implement. I question
whether this is actually needed. In other languages, I >do not< want
C++ exceptions to try and unwind my stack, nor do I want my exceptions
to unwind a C++ stack. The exceptions are completely incompatible and
this would not make sense.

To implement exceptions in a new frontend, unwind functionality is
required. LLVM generates all the stack frame information, so a
front-end author is not in the position to unwind the stack himself.
When I read the LLVM documentation I thought it could do this, and I
was extremely disappointed to learn that it could not.

This missing functionality means (as far as I can tell) that I will
not be able to implement a backend for ML which uses LLVM directly.
Instead I would need to use a trampoline to effectively remove LLVM
from stack control and manage a stack in the heap explicitly. This
seems quite a shame since LLVM was clearly intended to function as a
SSA backend.

I would ask that the documentation for unwind be updated to reflect
that this operation does not actually exist. Such a warning would have
saved me two weeks of wasted implementation effort.

[1] http://www.nabble.com/Unwinds-Gone-Wild-td18747589.html


From victor at optirisk-systems.com  Mon Jun 15 09:45:57 2009
From: victor at optirisk-systems.com (Victor Zverovich)
Date: Mon, 15 Jun 2009 17:45:57 +0100
Subject: [LLVMdev] runtime library for jitted code
In-Reply-To: <87ski1cxbl.fsf@telefonica.net>
References: <a88d534c0906150235w6f0e3ce3i4302f4eeae6b03d0@mail.gmail.com>
	<4A365D35.3040005@t-online.de> <87ski1cxbl.fsf@telefonica.net>
Message-ID: <a88d534c0906150945r268848e2p9212ba1c2e307dc9@mail.gmail.com>

Name mangling is not a problem, I just wanted to figure out if it is
necessary to declare all functions from the runtime library and map them to
the addresses manually.

Victor

2009/6/15 Óscar Fuentes <ofv at wanadoo.es>

> Albert Graef <Dr.Graef at t-online.de> writes:
>
> > Victor Zverovich wrote:
> >> I am considering a possibility of using LLVM JIT for an algebraic
> >> modelling language. I have already done some prototyping following the
> >> Kaleidoscope tutorial and currently thinking of how to connect the
> >> jitted code to a runtime library (for this language) which I would like
> >> to code in C++. If it was *NIX I would use g++ possibly with '-rdynamic'
> >> option as suggested in the tutorial to resolve required functions at
> >> runtime. However it is not an option, I am stuck to Windows and Visual
> >> C++.
> >
> > Well, backlinking doesn't work on Windows, but you can create a dll for
> > your runtime and use LLVM's dynamic library interface to load that dll.
> > I'm doing it that way in my project (http://pure-lang.googlecode.com/,
> > search for 'sys::DynamicLibrary::' in interpreter.cc) and it works fine
> > on Windows.
>
> The OP says that he wants to link to a dll coded in C++. Isn't name
> mangling the main problem here?
>
> --
> Óscar
>
> _______________________________________________
> 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.llvm.org/pipermail/llvm-dev/attachments/20090615/1849e310/attachment.html>

From aaronngray.lists at googlemail.com  Mon Jun 15 10:08:10 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Mon, 15 Jun 2009 18:08:10 +0100
Subject: [LLVMdev] unwind/invoke design
References: <162de7480906150946h549a0463k164017cb85c85ad0@mail.gmail.com>
Message-ID: <0AAD50C446D84D999871E50E61E472AE@HPLAPTOP>

> The documentation of unwind/invoke is quite clear and does exactly
> what I need: unwinding the stack. I don't need it to carry an object
> back. I don't need it to figure out what the type of the object is or
> what catch() blocks it matches. I just need it to unwind the stack.
> The rest is my job as a part of the runtime. Unfortunately, I have
> learned that while this works with the bytecode evaluator, it doesn't
> work with the JIT or native codegen [1].

DWARF EH maybe what you want, it has zero overhead on normal calls and I 
believe it is built into LLVM's assemblers. A DWARF style EH is also built 
into the JIT too.

Aaron



From wesley at terpstra.ca  Mon Jun 15 10:26:51 2009
From: wesley at terpstra.ca (Wesley W. Terpstra)
Date: Mon, 15 Jun 2009 19:26:51 +0200
Subject: [LLVMdev] unwind/invoke design
In-Reply-To: <0AAD50C446D84D999871E50E61E472AE@HPLAPTOP>
References: <162de7480906150946h549a0463k164017cb85c85ad0@mail.gmail.com>
	<0AAD50C446D84D999871E50E61E472AE@HPLAPTOP>
Message-ID: <162de7480906151026g2f0c9153u84279de5f070a652@mail.gmail.com>

On Mon, Jun 15, 2009 at 7:08 PM, Aaron
Gray<aaronngray.lists at googlemail.com> wrote:
>> The documentation of unwind/invoke is quite clear and does exactly
>> what I need: unwinding the stack. I don't need it to carry an object
>> back. I don't need it to figure out what the type of the object is or
>> what catch() blocks it matches. I just need it to unwind the stack.
>> The rest is my job as a part of the runtime. Unfortunately, I have
>> learned that while this works with the bytecode evaluator, it doesn't
>> work with the JIT or native codegen [1].
>
> DWARF EH maybe what you want, it has zero overhead on normal calls and I
> believe it is built into LLVM's assemblers. A DWARF style EH is also built
> into the JIT too.

How do I tell llc to output dwarf-style 'unwnd' ? Both -enable-eh and
-enable-correct-eh-support compile 'unwind' to nothing on x86 with llc
v2.5.


From edwintorok at gmail.com  Mon Jun 15 10:42:01 2009
From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=)
Date: Mon, 15 Jun 2009 20:42:01 +0300
Subject: [LLVMdev] unwind/invoke design
In-Reply-To: <162de7480906151026g2f0c9153u84279de5f070a652@mail.gmail.com>
References: <162de7480906150946h549a0463k164017cb85c85ad0@mail.gmail.com>	<0AAD50C446D84D999871E50E61E472AE@HPLAPTOP>
	<162de7480906151026g2f0c9153u84279de5f070a652@mail.gmail.com>
Message-ID: <4A3687E9.7060100@gmail.com>

On 2009-06-15 20:26, Wesley W. Terpstra wrote:
> On Mon, Jun 15, 2009 at 7:08 PM, Aaron
> Gray<aaronngray.lists at googlemail.com> wrote:
>   
>>> The documentation of unwind/invoke is quite clear and does exactly
>>> what I need: unwinding the stack. I don't need it to carry an object
>>> back. I don't need it to figure out what the type of the object is or
>>> what catch() blocks it matches. I just need it to unwind the stack.
>>> The rest is my job as a part of the runtime. Unfortunately, I have
>>> learned that while this works with the bytecode evaluator, it doesn't
>>> work with the JIT or native codegen [1].
>>>       
>> DWARF EH maybe what you want, it has zero overhead on normal calls and I
>> believe it is built into LLVM's assemblers. A DWARF style EH is also built
>> into the JIT too.
>>     
>
> How do I tell llc to output dwarf-style 'unwnd' ? Both -enable-eh and
> -enable-correct-eh-support compile 'unwind' to nothing on x86 with llc
> v2.5.
>   

Write some C++ code into llvm.org/demo, and watch the output assembly,
for example:
int foo() {
 throw 1;
}

int bar() {
try {
  foo();
} catch (...) {
}
}

That should show the basics of exception handling.

Best regards,
--Edwin


From wesley at terpstra.ca  Mon Jun 15 11:17:23 2009
From: wesley at terpstra.ca (Wesley W. Terpstra)
Date: Mon, 15 Jun 2009 20:17:23 +0200
Subject: [LLVMdev] unwind/invoke design
In-Reply-To: <4A3687E9.7060100@gmail.com>
References: <162de7480906150946h549a0463k164017cb85c85ad0@mail.gmail.com>
	<0AAD50C446D84D999871E50E61E472AE@HPLAPTOP>
	<162de7480906151026g2f0c9153u84279de5f070a652@mail.gmail.com>
	<4A3687E9.7060100@gmail.com>
Message-ID: <162de7480906151117v9d16870uff2c78ec5217e56b@mail.gmail.com>

2009/6/15 Török Edwin <edwintorok at gmail.com>:
> Write some C++ code into llvm.org/demo, and watch the output assembly,

That shows how to use the c++ runtime for handling c++ style
exceptions. More useful might be an llvm implementation of
__cxa_throw, which I could then modify. ;)



From dag at cray.com  Mon Jun 15 11:33:57 2009
From: dag at cray.com (David Greene)
Date: Mon, 15 Jun 2009 13:33:57 -0500
Subject: [LLVMdev] Regular Expressions
In-Reply-To: <3BD935DB-2D5B-4AC4-BD12-EDDE9F959757@apple.com>
References: <200906081700.n58H0Zvi022899@zion.cs.uiuc.edu>	<200906091439.18446.dag@cray.com>	<21EF7717-A7BE-44EE-B320-53A6BEEAE8EF@apple.com>	<200906111601.57203.dag@cray.com>
	<3BD935DB-2D5B-4AC4-BD12-EDDE9F959757@apple.com>
Message-ID: <4A369415.50207@cray.com>

Chris Lattner wrote:

> However, I don't see any reason to base this off of strings.  Instead  
> of passing down "f32" as a string, why not do something like this  
> pseudo code:
> 
> class X86ValueType {
>    RegisterClass RegClass;
>    ...
> }
> 
> def X86_f32 : X86ValueType {
>    let RegClass = FR32;
>    ... };
> def X86_i32 : X86ValueType { ... };
> 
> Then change fp_cvt_scalar_VXSnrr to be something like this:
> 
>> class fp_cvt_scalar_VXSnrr<
>> // Parent: avx_fp_cvt_scalar_xs_node_rm_DEF_V#NAME#_128rr
>>  bits<8> opc,
>>  string OpcodeStr,
>>  SDNode OpNode,
>>  X86ValueType DstType,
>>  X86ValueType SrcType,
>>  int CustomPatterns = 0,
>>  list<dag> patterns = [],
>>  string asm = ""
>>> : fp_unary_vxs_n_rm_rr<
>>    opc, DstType.RegClass,
> 
> This lets you encode whatever you want as properties of the dependent  
> class, makes everything "type safe", and eliminates string munging.   
> Would something like this work?

Yes, that will work for this case and is probably a better solution than
regular expressions.

There are other cases where I want to key off opcode strings and
there it's not practical to wrap each opcode in its own class.

For example:

!subst(SRCTYPE,
!cast<ValueType>(!patsubst(".*ps$","v4f32",!patsubst(".*pd$","v2f64",OpcodeStr))),

To reduce redundancy, developers must be able to write generic patterns
like this:

[(set DSTREGCLASS:$dst,  // rr, rrr
       (xor (INTSRCTYPE (bitconvert (SRCTYPE SRCREGCLASS:$src1))),
       (INTSRCTYPE (bitconvert (SRCTYPE SRCREGCLASS:$src2)))))],

The substitution then fills in the appropriate types, etc. based
on which variant (32-bit, 64-bit, AVX, etc.) is being produced.

I suppose you could argue that additional parameters specifying
the source and dest types could be passed, but why bother when
it is already encoded in the mnemonic?  That would just be
adding error-prone redundancy.

In fact while writing this stuff this pattern matching and
substitution already caught a few typing errors for us.

                                 -Dave


From hannibal_08 at mail.com  Mon Jun 15 11:47:15 2009
From: hannibal_08 at mail.com (hannibal hannibal)
Date: Mon, 15 Jun 2009 13:47:15 -0500
Subject: [LLVMdev] CROSS COMPILING LLVM
Message-ID: <20090615184715.421EC11581F@ws1-7.us4.outblaze.com>



----- Original Message -----
From: "Misha Brukman" 
To: "LLVM Developers Mailing List" 
Subject: Re: [LLVMdev] CROSS COMPILING LLVM
Date: Mon, 15 Jun 2009 12:41:17 -0400

2009/6/14 hannibal hannibal 


I was able to use your scripts to build  llvm and llvm-gcc successfully. But when i try to link to llvm libraries i get the following :

.........................
..........................
/arm-2007q3/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.1/../../../../arm-none-linux-gnueabi/bin/ld: /arm-llvm/llvm-project/i686-pc-linux-gnu/arm-none-linux-gnueabi/llvm/lib/LLVMXCore.o: Relocations in generic ELF (EM: 3)
/arm-llvm/llvm-project/i686-pc-linux-gnu/arm-none-linux-gnueabi/llvm/lib/LLVMXCore.o: could not read symbols: File in wrong format


What are you trying to do, exactly?  If you're trying to create an ARM executable which uses LLVM libraries, note that you'd have to also cross-compile LLVM first, using your new cross-compiler.  Otherwise, you're trying to link ARM object files with x86_64 LLVM libraries, which aren't compatible.


Note that I'm just guessing -- it's really hard to tell what's wrong without complete information, e.g. exact command lines, your host machine, your target machine, etc.


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


My apologies,I have realized my mistake. I am linking against the wrong libraries. 

Thanks for your help.


hannibal 


-- 
Be Yourself @ mail.com!
Choose From 200+ Email Addresses
Get a Free Account at www.mail.com




From eli.friedman at gmail.com  Mon Jun 15 12:18:03 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Mon, 15 Jun 2009 12:18:03 -0700
Subject: [LLVMdev] unwind/invoke design
In-Reply-To: <162de7480906151117v9d16870uff2c78ec5217e56b@mail.gmail.com>
References: <162de7480906150946h549a0463k164017cb85c85ad0@mail.gmail.com>
	<0AAD50C446D84D999871E50E61E472AE@HPLAPTOP>
	<162de7480906151026g2f0c9153u84279de5f070a652@mail.gmail.com>
	<4A3687E9.7060100@gmail.com>
	<162de7480906151117v9d16870uff2c78ec5217e56b@mail.gmail.com>
Message-ID: <f5aa3e9b0906151218s15edd918h1baa5dec083fc04d@mail.gmail.com>

On Mon, Jun 15, 2009 at 11:17 AM, Wesley W. Terpstra<wesley at terpstra.ca> wrote:
> 2009/6/15 Török Edwin <edwintorok at gmail.com>:
>> Write some C++ code into llvm.org/demo, and watch the output assembly,
>
> That shows how to use the c++ runtime for handling c++ style
> exceptions. More useful might be an llvm implementation of
> __cxa_throw, which I could then modify. ;)

See http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-May/022618.html .

-Eli



From baldrick at free.fr  Mon Jun 15 12:34:21 2009
From: baldrick at free.fr (Duncan Sands)
Date: Mon, 15 Jun 2009 21:34:21 +0200
Subject: [LLVMdev] unwind/invoke design
In-Reply-To: <162de7480906151117v9d16870uff2c78ec5217e56b@mail.gmail.com>
References: <162de7480906150946h549a0463k164017cb85c85ad0@mail.gmail.com>	<0AAD50C446D84D999871E50E61E472AE@HPLAPTOP>	<162de7480906151026g2f0c9153u84279de5f070a652@mail.gmail.com>	<4A3687E9.7060100@gmail.com>
	<162de7480906151117v9d16870uff2c78ec5217e56b@mail.gmail.com>
Message-ID: <4A36A23D.7080208@free.fr>

Wesley W. Terpstra wrote:
> 2009/6/15 Török Edwin <edwintorok at gmail.com>:
>> Write some C++ code into llvm.org/demo, and watch the output assembly,
> 
> That shows how to use the c++ runtime for handling c++ style
> exceptions. More useful might be an llvm implementation of
> __cxa_throw, which I could then modify. ;)

Take a look at _Unwind_RaiseException, which does the heavy
lifting in __cxa_throw.  It's part of libgcc.

Ciao,

Duncan.


From clattner at apple.com  Mon Jun 15 12:35:14 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 15 Jun 2009 12:35:14 -0700
Subject: [LLVMdev] Regular Expressions
In-Reply-To: <4A369415.50207@cray.com>
References: <200906081700.n58H0Zvi022899@zion.cs.uiuc.edu>
	<200906091439.18446.dag@cray.com>
	<21EF7717-A7BE-44EE-B320-53A6BEEAE8EF@apple.com>
	<200906111601.57203.dag@cray.com>
	<3BD935DB-2D5B-4AC4-BD12-EDDE9F959757@apple.com>
	<4A369415.50207@cray.com>
Message-ID: <09C9C325-2B00-4C3F-8A11-93FC60B2BDB4@apple.com>

On Jun 15, 2009, at 11:33 AM, David Greene wrote:
> To reduce redundancy, developers must be able to write generic  
> patterns
> like this:
>
> [(set DSTREGCLASS:$dst,  // rr, rrr
>       (xor (INTSRCTYPE (bitconvert (SRCTYPE SRCREGCLASS:$src1))),
>       (INTSRCTYPE (bitconvert (SRCTYPE SRCREGCLASS:$src2)))))],
>
> The substitution then fills in the appropriate types, etc. based
> on which variant (32-bit, 64-bit, AVX, etc.) is being produced.
>
> I suppose you could argue that additional parameters specifying
> the source and dest types could be passed, but why bother when
> it is already encoded in the mnemonic?  That would just be
> adding error-prone redundancy.

Why not synthesize the opcode string from the information passed down?

-Chris


From baldrick at free.fr  Mon Jun 15 12:40:30 2009
From: baldrick at free.fr (Duncan Sands)
Date: Mon, 15 Jun 2009 21:40:30 +0200
Subject: [LLVMdev] unwind/invoke design
In-Reply-To: <162de7480906150946h549a0463k164017cb85c85ad0@mail.gmail.com>
References: <162de7480906150946h549a0463k164017cb85c85ad0@mail.gmail.com>
Message-ID: <4A36A3AE.7080604@free.fr>

Hi Wesley,

> The documentation of unwind/invoke is quite clear and does exactly
> what I need: unwinding the stack. I don't need it to carry an object
> back. I don't need it to figure out what the type of the object is or
> what catch() blocks it matches. I just need it to unwind the stack.
> The rest is my job as a part of the runtime. Unfortunately, I have
> learned that while this works with the bytecode evaluator, it doesn't
> work with the JIT or native codegen [1].

you can call the libgcc/libunwind routines directly.  There was an
example of this on the mailing list by Talin not long ago.  That said,
it wouldn't be too hard to support "unwind" in the code generators.
It would basically mean creating thread-local storage to hold dwarf
exception information, and turning "unwind" into some code to set up
the info and call the appropriate libgcc routine.  Unfortunately no-one
was interested enough to do it yet.

Ciao,

Duncan.


From wesley at terpstra.ca  Mon Jun 15 14:55:24 2009
From: wesley at terpstra.ca (Wesley W. Terpstra)
Date: Mon, 15 Jun 2009 23:55:24 +0200
Subject: [LLVMdev] unwind/invoke design
In-Reply-To: <4A36A3AE.7080604@free.fr>
References: <162de7480906150946h549a0463k164017cb85c85ad0@mail.gmail.com>
	<4A36A3AE.7080604@free.fr>
Message-ID: <162de7480906151455k6bea2207w3803be4a64cf3918@mail.gmail.com>

On Mon, Jun 15, 2009 at 9:40 PM, Duncan Sands<baldrick at free.fr> wrote:
> you can call the libgcc/libunwind routines directly.  There was an
> example of this on the mailing list by Talin not long ago.

I'll look into this. Thanks.

> That said,
> it wouldn't be too hard to support "unwind" in the code generators.
> It would basically mean creating thread-local storage to hold dwarf
> exception information, and turning "unwind" into some code to set up
> the info and call the appropriate libgcc routine.

Why does 'unwind' need to setup thread local storage at all? In my
opinion this is the responsibility of the frontend, not LLVM. All I
expect 'unwind' to do is unwind the stack down to the nearest 'unwind
label' of an invoke. Thread-local storage, global variable, or any
other approach one might think of to carry the exception information
is a frontend policy decision. Adding this support to 'unwind'
complicates its implementation and also dilutes its usefulness.



From gohman at apple.com  Mon Jun 15 16:23:26 2009
From: gohman at apple.com (Dan Gohman)
Date: Mon, 15 Jun 2009 16:23:26 -0700
Subject: [LLVMdev] Upcoming API change: FAdd, FSub, FMul
Message-ID: <BBF63352-A55A-4EF9-AB08-66B85AC6B841@apple.com>

Hello,

The LLVM IR opcodes Add, Sub, and Mul have been each split into
two.  Add, Sub, and Mul now only handle integer types, and three
new opcodes, FAdd, FSub, and FMul now handle floating-point types.

The main LLVM APIs are currently preserving backwards
compatibility, transparently mapping integer opcodes to
corresponding floating-point opcodes when the operands have
floating-point types. This compatibility code will eventually be
removed, so front-end writers should update their front-ends to
use the new opcodes.  I've updated llvm-gcc as an example.

As an aid to this process, the attached patch can be applied to a
local LLVM tree to remove the backward-compatibility code, to
allow front-ends to be tested.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: add-fadd.patch
Type: application/octet-stream
Size: 3166 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090615/a38f33ff/attachment.obj>
-------------- next part --------------


Dan


From dag at cray.com  Mon Jun 15 16:43:58 2009
From: dag at cray.com (David Greene)
Date: Mon, 15 Jun 2009 18:43:58 -0500
Subject: [LLVMdev] Some understanding of LLVM vs gCC vs Intel C++
	Compilers
In-Reply-To: <fa28b9250906142332p27914ab3hb90ae6e93781884@mail.gmail.com>
References: <FAD2E372-2FC6-410E-9ECE-1AEAD896996D@MailNewsRSS.com>
	<6F675FC4-66EA-46BF-93D5-F29B154492B0@MailNewsRSS.com>
	<fa28b9250906142332p27914ab3hb90ae6e93781884@mail.gmail.com>
Message-ID: <200906151843.58729.dag@cray.com>

On Monday 15 June 2009 01:32, me22 wrote:

> My (possibly faultly) understanding is that intel's has good support
> for numerics, presumably through auto-vectorization and such, but only

Yes, that's true.

> works for intel's architectures and is only excellent on intel chips.

That used to be the case, but not so anymore.  Intel compilers generate
just fine code for AMD processors.  Since AMD doesn't produce their
own compilers, it's likely on par with any other vendor producing an
AMD compiler.

Well, except for Cray, that is.  :)

*ducks*

But hey, we use LLVM to do it!

                                      -Dave


From me22.ca at gmail.com  Mon Jun 15 17:02:31 2009
From: me22.ca at gmail.com (me22)
Date: Mon, 15 Jun 2009 17:02:31 -0700
Subject: [LLVMdev] Some understanding of LLVM vs gCC vs Intel C++
	Compilers
In-Reply-To: <200906151843.58729.dag@cray.com>
References: <FAD2E372-2FC6-410E-9ECE-1AEAD896996D@MailNewsRSS.com> 
	<6F675FC4-66EA-46BF-93D5-F29B154492B0@MailNewsRSS.com>
	<fa28b9250906142332p27914ab3hb90ae6e93781884@mail.gmail.com> 
	<200906151843.58729.dag@cray.com>
Message-ID: <fa28b9250906151702k705c9f78gaaa22b009aaca3ea@mail.gmail.com>

2009/6/15 David Greene <dag at cray.com>:
> On Monday 15 June 2009 01:32, me22 wrote:
>> [...] works for intel's architectures and is only excellent on intel chips.
>
> That used to be the case, but not so anymore.  Intel compilers generate
> just fine code for AMD processors.  Since AMD doesn't produce their
> own compilers, it's likely on par with any other vendor producing an
> AMD compiler.
>

"On par with any other vendor" doesn't count as "excellent", to me,
but fair enough.



From dag at cray.com  Mon Jun 15 17:30:16 2009
From: dag at cray.com (David Greene)
Date: Mon, 15 Jun 2009 19:30:16 -0500
Subject: [LLVMdev] Some understanding of LLVM vs gCC vs Intel C++
	Compilers
In-Reply-To: <fa28b9250906151702k705c9f78gaaa22b009aaca3ea@mail.gmail.com>
References: <FAD2E372-2FC6-410E-9ECE-1AEAD896996D@MailNewsRSS.com>
	<200906151843.58729.dag@cray.com>
	<fa28b9250906151702k705c9f78gaaa22b009aaca3ea@mail.gmail.com>
Message-ID: <200906151930.17350.dag@cray.com>

On Monday 15 June 2009 19:02, me22 wrote:
> 2009/6/15 David Greene <dag at cray.com>:
> > On Monday 15 June 2009 01:32, me22 wrote:
> >> [...] works for intel's architectures and is only excellent on intel
> >> chips.
> >
> > That used to be the case, but not so anymore.  Intel compilers generate
> > just fine code for AMD processors.  Since AMD doesn't produce their
> > own compilers, it's likely on par with any other vendor producing an
> > AMD compiler.
>
> "On par with any other vendor" doesn't count as "excellent", to me,
> but fair enough.

Intel doesn't have the internal AMD designs so it can't make use of 
proprietary knowledge as it can for Intel chips.  But then, no AMD
compiler vendor can, so they're all operating on a level playing
field.  That's all I meant.  It is faster on some codes than other
AMD compilers.  On other codes, it's slower.  This is no different
than any other compiler.

                                  -Dave



From victor at optirisk-systems.com  Mon Jun 15 09:48:23 2009
From: victor at optirisk-systems.com (Victor Zverovich)
Date: Mon, 15 Jun 2009 17:48:23 +0100
Subject: [LLVMdev] runtime library for jitted code
In-Reply-To: <4A365D35.3040005@t-online.de>
References: <a88d534c0906150235w6f0e3ce3i4302f4eeae6b03d0@mail.gmail.com>
	<4A365D35.3040005@t-online.de>
Message-ID: <a88d534c0906150948h3f58c8d2s5113bc3482be3c41@mail.gmail.com>

Albert and Anton, thanks for all the answers.
I tried to load a DLL with DynamicLibrary::LoadLibraryPermanently and it
works perfectly, so there is no need to use
ExecutionEngine::addGlobalMapping. However Function objects still need to be
constructed since they are required when creating a call, right?

Victor

2009/6/15 Albert Graef <Dr.Graef at t-online.de>

> Victor Zverovich wrote:
> > I am considering a possibility of using LLVM JIT for an algebraic
> > modelling language. I have already done some prototyping following the
> > Kaleidoscope tutorial and currently thinking of how to connect the
> > jitted code to a runtime library (for this language) which I would like
> > to code in C++. If it was *NIX I would use g++ possibly with '-rdynamic'
> > option as suggested in the tutorial to resolve required functions at
> > runtime. However it is not an option, I am stuck to Windows and Visual
> > C++.
>
> Well, backlinking doesn't work on Windows, but you can create a dll for
> your runtime and use LLVM's dynamic library interface to load that dll.
> I'm doing it that way in my project (http://pure-lang.googlecode.com/,
> search for 'sys::DynamicLibrary::' in interpreter.cc) and it works fine
> on Windows.
>
> Albert
>
> --
> Dr. Albert Gr"af
> Dept. of Music-Informatics, University of Mainz, Germany
> Email:  Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de
> WWW:    http://www.musikinformatik.uni-mainz.de/ag
> _______________________________________________
> 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.llvm.org/pipermail/llvm-dev/attachments/20090615/3f4dc042/attachment.html>

From eli.friedman at gmail.com  Mon Jun 15 17:43:16 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Mon, 15 Jun 2009 17:43:16 -0700
Subject: [LLVMdev] Some understanding of LLVM vs gCC vs Intel C++
	Compilers
In-Reply-To: <200906151843.58729.dag@cray.com>
References: <FAD2E372-2FC6-410E-9ECE-1AEAD896996D@MailNewsRSS.com>
	<6F675FC4-66EA-46BF-93D5-F29B154492B0@MailNewsRSS.com>
	<fa28b9250906142332p27914ab3hb90ae6e93781884@mail.gmail.com>
	<200906151843.58729.dag@cray.com>
Message-ID: <f5aa3e9b0906151743u58463d6aib8aed543e74ecddd@mail.gmail.com>

On Mon, Jun 15, 2009 at 4:43 PM, David Greene<dag at cray.com> wrote:
> On Monday 15 June 2009 01:32, me22 wrote:
>
>> My (possibly faultly) understanding is that intel's has good support
>> for numerics, presumably through auto-vectorization and such, but only
>
> Yes, that's true.
>
>> works for intel's architectures and is only excellent on intel chips.
>
> That used to be the case, but not so anymore.  Intel compilers generate
> just fine code for AMD processors.

Per http://www.agner.org/optimize/, Intel's compiler doesn't use
vectorized codepaths on AMD chips by default; I don't know whether
that has changed in more recent versions.

-Eli



From Benedict.Gaster at amd.com  Mon Jun 15 17:49:03 2009
From: Benedict.Gaster at amd.com (Gaster, Benedict)
Date: Tue, 16 Jun 2009 02:49:03 +0200
Subject: [LLVMdev] x86 Intel Syntax and MASM 9.x
Message-ID: <D79A8D1CEFA38E45AD075F6EB49D9E8C0D53EFC6@sefsexmb1.amd.com>

I would like to use the LLVM x86 code generator to emit Intel syntax
that is compatible with Microsoft's MASM 9.x. Taking the TOT LLVM, from
last week, I have found a number of changes that are required to make
this work, most of which are straight forward but a couple I wanted to
check with the group to see what people thought was the best thing to
do. In particular, I have made all necessary changes and these are
mostly constrained to the files:

 

               X86IntelAsmPrinter.[h|cpp]

               X86TargetAsmInfo.[h|cpp]

 

Making sure the syntax follows Microsoft MASM requirements. 

 

The main problem that I have hit is regarding the use of CL register in
the shift instructions. The problem is that ATT syntax states that it
should be referenced as "%cl" while Intel says just "cl" but these
references occur in X86InstInfo.td and this means that it is shared
between Intel and ATT printing! For example, the shift rules:

 

let Uses = [CL] in {

def SHL8rCL  : I<0xD2, MRM4r, (outs GR8 :$dst), (ins GR8 :$src),

                 "shl{b}\t{%cl, $dst|$dst, %CL}",

                 [(set GR8:$dst, (shl GR8:$src, %CL))]>;

def SHL16rCL : I<0xD3, MRM4r, (outs GR16:$dst), (ins GR16:$src),

                 "shl{w}\t{%cl, $dst|$dst, %CL}",

                 [(set GR16:$dst, (shl GR16:$src, %CL))]>, OpSize;

def SHL32rCL : I<0xD3, MRM4r, (outs GR32:$dst), (ins GR32:$src),

                 "shl{l}\t{%cl, $dst|$dst, %CL}",

                 [(set GR32:$dst, (shl GR32:$src, %CL))]>;

} // Uses = [CL]

 

Needs to be:

 

let Uses = [CL] in {

def SHL8rCL  : I<0xD2, MRM4r, (outs GR8 :$dst), (ins GR8 :$src),

                 "shl{b}\t{%cl, $dst|$dst, CL}",

                 [(set GR8:$dst, (shl GR8:$src, CL))]>;

def SHL16rCL : I<0xD3, MRM4r, (outs GR16:$dst), (ins GR16:$src),

                 "shl{w}\t{%cl, $dst|$dst, CL}",

                 [(set GR16:$dst, (shl GR16:$src, CL))]>, OpSize;

def SHL32rCL : I<0xD3, MRM4r, (outs GR32:$dst), (ins GR32:$src),

                 "shl{l}\t{%cl, $dst|$dst, CL}",

                 [(set GR32:$dst, (shl GR32:$src, CL))]>;

} // Uses = [CL]

 

The problem is that it does not make sense to have separate rules for
Intel and ATT and as such I wanted to get the lists advice on what
people think is the best approach to resolving this issue so I can make
the changes?

 

It is also worth noting that MASM does not allow:

 

               shr ESI

 

to be mean shift by 1 and instead I have to emit:

 

               shr ESI, 1

 

which I'm assuming is not an issue?

 

Finally, as far as I can tell from comments on the mailing list the
current Intel syntax emitted by LLVM does not work with any particular
Window's assembler and so making these changes will not cause another
path to stop working, is this correct?

 

Many thanks,

 

Ben

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090616/cd95c49f/attachment.html>

From resistor at mac.com  Mon Jun 15 18:16:49 2009
From: resistor at mac.com (Owen Anderson)
Date: Mon, 15 Jun 2009 18:16:49 -0700
Subject: [LLVMdev] UPCOMING API CHANGE: Threads and LLVM
Message-ID: <BB9EB6C4-21F6-47BA-BD49-AAE755D07946@mac.com>

Hey folks,

As you may be aware if you've been watching llvm-commits, I've been  
working recently on improving the ability to use LLVM across multiple  
threads.  While the goal for now is to be able to hack on multiple  
Module's in parallel, this has necessitated a larger review of how  
LLVM interacts with threads.

In a recent(-ish) patch, I added a new API: llvm_start_multithreaded 
().  This API is used to initialize the thread-safety constructs that  
are going into LLVM.  I will be committing a detail update to the LLVM  
programmer's manual on how to use it.

The major CHANGE is:  the JIT will no longer be safe for executing  
threaded applications without first invoking llvm_start_multithreaded 
().  Please begin to update your client applications now if this  
affects you, as I will be throwing the switch in SVN sooner rather  
than later.

Thanks,

--Owen


From Dr.Graef at t-online.de  Mon Jun 15 18:35:16 2009
From: Dr.Graef at t-online.de (Albert Graef)
Date: Tue, 16 Jun 2009 03:35:16 +0200
Subject: [LLVMdev] runtime library for jitted code
In-Reply-To: <a88d534c0906150948h3f58c8d2s5113bc3482be3c41@mail.gmail.com>
References: <a88d534c0906150235w6f0e3ce3i4302f4eeae6b03d0@mail.gmail.com>	<4A365D35.3040005@t-online.de>
	<a88d534c0906150948h3f58c8d2s5113bc3482be3c41@mail.gmail.com>
Message-ID: <4A36F6D4.1010303@t-online.de>

Victor Zverovich wrote:
> I tried to load a DLL with DynamicLibrary::LoadLibraryPermanently and it
> works perfectly, so there is no need to use
> ExecutionEngine::addGlobalMapping. However Function objects still need
> to be constructed since they are required when creating a call, right?

Yes, basically you need to construct the IR for a body-less function
with external binding, the JIT will then try to resolve it when you call
the function.

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de
WWW:    http://www.musikinformatik.uni-mainz.de/ag


From eli.friedman at gmail.com  Mon Jun 15 18:43:56 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Mon, 15 Jun 2009 18:43:56 -0700
Subject: [LLVMdev] x86 Intel Syntax and MASM 9.x
In-Reply-To: <D79A8D1CEFA38E45AD075F6EB49D9E8C0D53EFC6@sefsexmb1.amd.com>
References: <D79A8D1CEFA38E45AD075F6EB49D9E8C0D53EFC6@sefsexmb1.amd.com>
Message-ID: <f5aa3e9b0906151843g22b608a7u8397ee4854f17392@mail.gmail.com>

On Mon, Jun 15, 2009 at 5:49 PM, Gaster,
Benedict<Benedict.Gaster at amd.com> wrote:
> I would like to use the LLVM x86 code generator to emit Intel syntax that is
> compatible with Microsoft’s MASM 9.x. Taking the TOT LLVM, from last week, I
> have found a number of changes that are required to make this work, most of
> which are straight forward but a couple I wanted to check with the group to
> see what people thought was the best thing to do. In particular, I have made
> all necessary changes and these are mostly constrained to the files:
>
>
>
>                X86IntelAsmPrinter.[h|cpp]
>
>                X86TargetAsmInfo.[h|cpp]

Sounds good; did you mean to attach a patch?  It'll be easier to
discuss with that.  (The output of "svn diff" is fine.)

> The main problem that I have hit is regarding the use of CL register in the
> shift instructions. The problem is that ATT syntax states that it should be
> referenced as “%cl” while Intel says just “cl” but these references occur in
> X86InstInfo.td and this means that it is shared between Intel and ATT
> printing! For example, the shift rules:

We have two different output styles for precisely that reason.

> The problem is that it does not make sense to have separate rules for Intel
> and ATT and as such I wanted to get the lists advice on what people think is
> the best approach to resolving this issue so I can make the changes?

The changes just mentioned looks correct.

> It is also worth noting that MASM does not allow:
>                shr ESI
> to be mean shift by 1 and instead I have to emit:
>                shr ESI, 1
> which I’m assuming is not an issue?

That's fine.

> Finally, as far as I can tell from comments on the mailing list the current
> Intel syntax emitted by LLVM does not work with any particular Window’s
> assembler and so making these changes will not cause another path to stop
> working, is this correct?

MASM is about as canonical as it gets for standard Intel syntax, and
the changes look reasonable.

-Eli



From deeppatel1987 at gmail.com  Mon Jun 15 18:53:28 2009
From: deeppatel1987 at gmail.com (Sandeep Patel)
Date: Mon, 15 Jun 2009 18:53:28 -0700
Subject: [LLVMdev] UPCOMING API CHANGE: Threads and LLVM
In-Reply-To: <BB9EB6C4-21F6-47BA-BD49-AAE755D07946@mac.com>
References: <BB9EB6C4-21F6-47BA-BD49-AAE755D07946@mac.com>
Message-ID: <305d6f60906151853w7456dec7ya05084888a064c74@mail.gmail.com>

This question is a bit of far away future thought:

There's traditionally been a fundamental assumption that static
compilers are single-threaded. Many build systems assume this and
support assigning compilation jobs with one job per processor.

If the compiler becomes multi-threaded internally, how should the
build system best schedule compilation jobs?

deep

On Mon, Jun 15, 2009 at 6:16 PM, Owen Anderson<resistor at mac.com> wrote:
> Hey folks,
>
> As you may be aware if you've been watching llvm-commits, I've been
> working recently on improving the ability to use LLVM across multiple
> threads.  While the goal for now is to be able to hack on multiple
> Module's in parallel, this has necessitated a larger review of how
> LLVM interacts with threads.
>
> In a recent(-ish) patch, I added a new API: llvm_start_multithreaded
> ().  This API is used to initialize the thread-safety constructs that
> are going into LLVM.  I will be committing a detail update to the LLVM
> programmer's manual on how to use it.
>
> The major CHANGE is:  the JIT will no longer be safe for executing
> threaded applications without first invoking llvm_start_multithreaded
> ().  Please begin to update your client applications now if this
> affects you, as I will be throwing the switch in SVN sooner rather
> than later.
>
> Thanks,
>
> --Owen
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>



From resistor at mac.com  Mon Jun 15 19:07:29 2009
From: resistor at mac.com (Owen Anderson)
Date: Mon, 15 Jun 2009 19:07:29 -0700
Subject: [LLVMdev] UPCOMING API CHANGE: Threads and LLVM
In-Reply-To: <305d6f60906151853w7456dec7ya05084888a064c74@mail.gmail.com>
References: <BB9EB6C4-21F6-47BA-BD49-AAE755D07946@mac.com>
	<305d6f60906151853w7456dec7ya05084888a064c74@mail.gmail.com>
Message-ID: <22A0CA27-4145-4821-BA98-E039E1857195@mac.com>

Sandeep,

That's somewhat orthogonal to what is being worked on right now.

This is not an effort to make LLVM internally multithreaded, but to  
allow clients of the LLVM APIs to make multiple, concurrent calls into  
the APIs from multiple threads, which obviously necessitates guarding  
our internal state with mutexes.  Threading LLVM itself is another,  
even larger, undertaking.

--Owen

On Jun 15, 2009, at 6:53 PM, Sandeep Patel wrote:

> This question is a bit of far away future thought:
>
> There's traditionally been a fundamental assumption that static
> compilers are single-threaded. Many build systems assume this and
> support assigning compilation jobs with one job per processor.
>
> If the compiler becomes multi-threaded internally, how should the
> build system best schedule compilation jobs?
>
> deep
>
> On Mon, Jun 15, 2009 at 6:16 PM, Owen Anderson<resistor at mac.com>  
> wrote:
>> Hey folks,
>>
>> As you may be aware if you've been watching llvm-commits, I've been
>> working recently on improving the ability to use LLVM across multiple
>> threads.  While the goal for now is to be able to hack on multiple
>> Module's in parallel, this has necessitated a larger review of how
>> LLVM interacts with threads.
>>
>> In a recent(-ish) patch, I added a new API: llvm_start_multithreaded
>> ().  This API is used to initialize the thread-safety constructs that
>> are going into LLVM.  I will be committing a detail update to the  
>> LLVM
>> programmer's manual on how to use it.
>>
>> The major CHANGE is:  the JIT will no longer be safe for executing
>> threaded applications without first invoking llvm_start_multithreaded
>> ().  Please begin to update your client applications now if this
>> affects you, as I will be throwing the switch in SVN sooner rather
>> than later.
>>
>> Thanks,
>>
>> --Owen
>> _______________________________________________
>> 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: 2620 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090615/3a387cb5/attachment.bin>

From jon at ffconsultancy.com  Mon Jun 15 22:51:42 2009
From: jon at ffconsultancy.com (Jon Harrop)
Date: Tue, 16 Jun 2009 06:51:42 +0100
Subject: [LLVMdev] Some understanding of LLVM vs gCC vs Intel C++
	Compilers
In-Reply-To: <200906151843.58729.dag@cray.com>
References: <FAD2E372-2FC6-410E-9ECE-1AEAD896996D@MailNewsRSS.com>
	<fa28b9250906142332p27914ab3hb90ae6e93781884@mail.gmail.com>
	<200906151843.58729.dag@cray.com>
Message-ID: <200906160651.42044.jon@ffconsultancy.com>

On Tuesday 16 June 2009 00:43:58 David Greene wrote:
> But hey, we use LLVM to do it!

Hello David,

I just noticed your post and was wondering what Cray are doing with LLVM? Are 
you using it in production?

I am trying to keep an eye on the fast moving LLVM project and like to keep up 
to date with respect to its industrial applications...

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e


From jon at ffconsultancy.com  Mon Jun 15 22:58:42 2009
From: jon at ffconsultancy.com (Jon Harrop)
Date: Tue, 16 Jun 2009 06:58:42 +0100
Subject: [LLVMdev] ML types in LLVM
In-Reply-To: <162de7480906140609y3c1f0584if03caa7bd993e43c@mail.gmail.com>
References: <162de7480906130354m430f9e17ndbf03b41592ab982@mail.gmail.com>
	<877hzfqjvu.fsf@mid.deneb.enyo.de>
	<162de7480906140609y3c1f0584if03caa7bd993e43c@mail.gmail.com>
Message-ID: <200906160658.42914.jon@ffconsultancy.com>

On Sunday 14 June 2009 14:09:33 Wesley W. Terpstra wrote:
> On Sun, Jun 14, 2009 at 10:50 AM, Florian Weimer<fw at deneb.enyo.de> wrote:
> > Is this really a problem for MLton?  I think you only get less precise
> > alias analysis, and that's it.
>
> Correct. However, I want a fair comparison between LLVM performance
> and the native x86 codegen. If I don't give LLVM the same information
> the x86 codegen has, it's an unfair comparison.

Even if this puts LLVM at an unfair disadvantage, I think you will find that 
LLVM will thrash MLton's current x86 backend anyway.

I did some benchmarking on HLVM and found that it was often several times 
faster than OCaml when the GC is not the bottleneck:

http://flyingfrogblog.blogspot.com/2009/03/performance-ocaml-vs-hlvm-beta-04.html

And, of course, OCaml is fast as ML compilers go...

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e



From viridia at gmail.com  Mon Jun 15 22:57:13 2009
From: viridia at gmail.com (Talin)
Date: Mon, 15 Jun 2009 22:57:13 -0700
Subject: [LLVMdev] unwind/invoke design
In-Reply-To: <162de7480906151455k6bea2207w3803be4a64cf3918@mail.gmail.com>
References: <162de7480906150946h549a0463k164017cb85c85ad0@mail.gmail.com>	<4A36A3AE.7080604@free.fr>
	<162de7480906151455k6bea2207w3803be4a64cf3918@mail.gmail.com>
Message-ID: <4A373439.4050704@gmail.com>

Wesley W. Terpstra wrote:
>> That said,
>> it wouldn't be too hard to support "unwind" in the code generators.
>> It would basically mean creating thread-local storage to hold dwarf
>> exception information, and turning "unwind" into some code to set up
>> the info and call the appropriate libgcc routine.
>>     
>
> Why does 'unwind' need to setup thread local storage at all? In my
> opinion this is the responsibility of the frontend, not LLVM. All I
> expect 'unwind' to do is unwind the stack down to the nearest 'unwind
> label' of an invoke. Thread-local storage, global variable, or any
> other approach one might think of to carry the exception information
> is a frontend policy decision. Adding this support to 'unwind'
> complicates its implementation and also dilutes its usefulness.
>   
Much to my surprise, I discovered that you do not need thread-local data 
at all - the address of the exception object can be passed in to the 
landing pad code by directly modifying a register (via the libunwind 
library API). The libunwind API also allows specification of a cleanup 
function to deallocate the exception object, although this is not needed 
in my case because I use garbage collection.

Since my previous posted example apparently turned out to be useful 
after all, maybe I should look in to putting it somewhere more permanent...

-- Talin



From Benedict.Gaster at amd.com  Mon Jun 15 23:21:30 2009
From: Benedict.Gaster at amd.com (Gaster, Benedict)
Date: Tue, 16 Jun 2009 08:21:30 +0200
Subject: [LLVMdev] x86 Intel Syntax and MASM 9.x
In-Reply-To: <f5aa3e9b0906151843g22b608a7u8397ee4854f17392@mail.gmail.com>
References: <D79A8D1CEFA38E45AD075F6EB49D9E8C0D53EFC6@sefsexmb1.amd.com>
	<f5aa3e9b0906151843g22b608a7u8397ee4854f17392@mail.gmail.com>
Message-ID: <D79A8D1CEFA38E45AD075F6EB49D9E8C0D53F004@sefsexmb1.amd.com>

Hi Eli,

Thanks for the response I have one question inline.

Regards,

Ben

[...]

> The main problem that I have hit is regarding the use of CL register
in the
> shift instructions. The problem is that ATT syntax states that it
should be
> referenced as "%cl" while Intel says just "cl" but these references
occur in
> X86InstInfo.td and this means that it is shared between Intel and ATT
> printing! For example, the shift rules:

We have two different output styles for precisely that reason.

> The problem is that it does not make sense to have separate rules for
Intel
> and ATT and as such I wanted to get the lists advice on what people
think is
> the best approach to resolving this issue so I can make the changes?

The changes just mentioned looks correct.

[bg]The problem is I am not sure of the best approach to take here. For
example, one possible approach I can see is to following that of the
HasSSE2 constraint and introduce something like the follow to X86.td:

def IsIntelAsmWriter : Predicate<"Subtarget.isFlavorIntel()">; 
def IsATTAsmWriter   : Predicate<"!Subtarget.isFlavorIntel()">;

and then in X86InstrInfo.td make changes something like:

  def SHL8mCLIntel  : I<0xD2, MRM4m, (outs), (ins i8mem :$dst),
				   "shl{b}\t{%cl, $dst|$dst, CL}",
				   [(store (shl (loadi8 addr:$dst), CL),
addr:$dst)]>, requires<[IsIntelAsmWriter]>;

  def SHL8mCLATT  : I<0xD2, MRM4m, (outs), (ins i8mem :$dst),
				   "shl{b}\t{%cl, $dst|$dst, %CL}",
				   [(store (shl (loadi8 addr:$dst), CL),
addr:$dst)]>, requires<[IsATTAsmWriter]>;

I can get this two work with additional changes to X86InstrInfocpp but
the problem I have with this approach is that it introduces a lot of
duplication, when all I really want to do is parameterize the final
field in the string "shl{b}\t{%cl, $dst|$dst, %CL}". I was wondering
(hoping :-) if you knew of a better method to handling this?

[...]

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





From viridia at gmail.com  Mon Jun 15 23:37:32 2009
From: viridia at gmail.com (Talin)
Date: Mon, 15 Jun 2009 23:37:32 -0700
Subject: [LLVMdev] Garbage Collection Project
Message-ID: <4A373DAC.9060807@gmail.com>

A while back there was a discussion thread about whether an accurate, 
concurrent garbage collector could be "generic" in the sense of being 
able to support multiple different languages efficiently. After having 
done some work on this, I now believe that this is the case - using C++ 
policy-based design principles, you can create a set of modules that 
represent different aspects of collector behavior (such as 
mark-and-sweep, stop-the-world, and so on) along with different aspects 
of the runtime environment (object tracing strategies, heap structures, 
threading primitives, atomics), and encode these various behaviors as 
template classes which can be bound together to create an efficient 
collector.

The work I have done so far can be found here:

   http://code.google.com/p/scarcity/

At the moment, it's still in the "toy" stage, meaning you can run the 
unit tests and you can write toy languages that use concurrent garbage 
collection. It is by no means ready for real-world use. It does not yet 
have support for incremental or generational collection, nor does it 
have weak pointer or pinning support yet. It is not yet integrated with 
LLVM's garbage collection intrinsics, although that too is planned. 
There's also at least one data race bug lurking in the code somewhere, 
which I have not yet been able to tease out with valgrind.

The project is now at the stage where a small number of additional 
eyeballs would be useful, which is why I'm posting this here.

-- Talin



From baldrick at free.fr  Mon Jun 15 23:42:36 2009
From: baldrick at free.fr (Duncan Sands)
Date: Tue, 16 Jun 2009 08:42:36 +0200
Subject: [LLVMdev] unwind/invoke design
In-Reply-To: <162de7480906151455k6bea2207w3803be4a64cf3918@mail.gmail.com>
References: <162de7480906150946h549a0463k164017cb85c85ad0@mail.gmail.com>	<4A36A3AE.7080604@free.fr>
	<162de7480906151455k6bea2207w3803be4a64cf3918@mail.gmail.com>
Message-ID: <4A373EDC.90508@free.fr>

Hi Wesley,

> Why does 'unwind' need to setup thread local storage at all? In my
> opinion this is the responsibility of the frontend, not LLVM. All I
> expect 'unwind' to do is unwind the stack down to the nearest 'unwind
> label' of an invoke.

sure, but how is it to do that?  Answer: using the libgcc unwinder
routines (another possibility is to use libunwind, which seems better
adapted to this but unfortunately isn't available everywhere).  But
the libgcc unwinder requires you to supply some storage for it, and
I don't see that you have any choice except to use thread-local
storage.

Thread-local storage, global variable, or any
> other approach one might think of to carry the exception information
> is a frontend policy decision. Adding this support to 'unwind'
> complicates its implementation and also dilutes its usefulness.

It would be entirely for technical reasons, see above.

Ciao,

Duncan.


From eli.friedman at gmail.com  Tue Jun 16 00:09:32 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Tue, 16 Jun 2009 00:09:32 -0700
Subject: [LLVMdev] x86 Intel Syntax and MASM 9.x
In-Reply-To: <D79A8D1CEFA38E45AD075F6EB49D9E8C0D53F004@sefsexmb1.amd.com>
References: <D79A8D1CEFA38E45AD075F6EB49D9E8C0D53EFC6@sefsexmb1.amd.com>
	<f5aa3e9b0906151843g22b608a7u8397ee4854f17392@mail.gmail.com>
	<D79A8D1CEFA38E45AD075F6EB49D9E8C0D53F004@sefsexmb1.amd.com>
Message-ID: <f5aa3e9b0906160009v37c61ca2q125522caf59b77df@mail.gmail.com>

On Mon, Jun 15, 2009 at 11:21 PM, Gaster,
Benedict<Benedict.Gaster at amd.com> wrote:
> I can get this two work with additional changes to X86InstrInfocpp but
> the problem I have with this approach is that it introduces a lot of
> duplication, when all I really want to do is parameterize the final
> field in the string "shl{b}\t{%cl, $dst|$dst, %CL}". I was wondering
> (hoping :-) if you knew of a better method to handling this?

I think you're missing the whole point of the "|" construct; the left
side is AT&T syntax, the right side is Intel syntax.

-Eli


From sanjiv.gupta at microchip.com  Tue Jun 16 02:35:18 2009
From: sanjiv.gupta at microchip.com (Sanjiv Gupta)
Date: Tue, 16 Jun 2009 15:05:18 +0530
Subject: [LLVMdev] Localizing Globals ?
Message-ID: <4A376756.9010302@microchip.com>

The code excerpt is from IPO/GlobalOpt.cpp


 // If this is a first class global and has only one accessing function
    // and this function is main (which we know is not recursive we can make
    // this global a local variable) we replace the global with a local 
alloca
    // in this function.
    //
    // NOTE: It doesn't make sense to promote non single-value types 
since we
    // are just replacing static memory to stack memory.
    if (!GS.HasMultipleAccessingFunctions &&
        GS.AccessingFunction && !GS.HasNonInstructionUser &&
        GV->getType()->getElementType()->isSingleValueType() &&
        GS.AccessingFunction->getName() == "main" &&
        GS.AccessingFunction->hasExternalLinkage()) {
      DOUT << "LOCALIZING GLOBAL: " << *GV;

What if my global variable was into a different address space than stack?
How do I deny this optimization in that case? Can I find address space 
for stack from AllocaInst and then compare the address spaces for two?

- Sanjiv



From eli.friedman at gmail.com  Tue Jun 16 03:10:19 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Tue, 16 Jun 2009 03:10:19 -0700
Subject: [LLVMdev] Localizing Globals ?
In-Reply-To: <4A376756.9010302@microchip.com>
References: <4A376756.9010302@microchip.com>
Message-ID: <f5aa3e9b0906160310y223ae6d7ve0842397b7f2594c@mail.gmail.com>

On Tue, Jun 16, 2009 at 2:35 AM, Sanjiv Gupta<sanjiv.gupta at microchip.com> wrote:
> What if my global variable was into a different address space than stack?

It doesn't matter in terms of semantics: because AnalyzeGlobal
returned false, we're guaranteed the address of the global is never
taken.  I wouldn't be surprised if we end up generating invalid IR in
some cases, though, because of the semantics of replaceAllUsesWith.
Do you have a testcase that breaks?

> How do I deny this optimization in that case? Can I find address space
> for stack from AllocaInst and then compare the address spaces for two?

An alloca is guaranteed to be in address space zero, so you can just
check something like "GV->getType()->getAddressSpace() == 0".

-Eli


From hannibal_08 at mail.com  Tue Jun 16 04:05:16 2009
From: hannibal_08 at mail.com (hannibal hannibal)
Date: Tue, 16 Jun 2009 06:05:16 -0500
Subject: [LLVMdev] undefined references in llvm
Message-ID: <20090616110516.AEE64326701@ws1-8.us4.outblaze.com>

Hello EveryOne,

I am building customized tools for ARM using a crosscomplier. I am
currently building a tool similar to lli but it only jits code. I
enabled jit when I was configuring LLVM. On linking my code with
help from llvm-config to the libraries I get this error:

Can't exec "which": No such file or directory at
llvm2/bin/llvm-config line 69.
Use of uninitialized value in scalar chomp at llvm2/bin/llvm-config line
70.
Use of uninitialized value in -e at llvm2/bin/llvm-config line 71.
/tmp/cc0b5iTo.o: In function `ForceCodegenLinking':
llvm2/include/llvm/CodeGen/LinkAllCodegenComponents.h:32: undefined
reference to `llvm::createDeadMachineInstructionElimPass()'
llvm2/include/llvm/CodeGen/LinkAllCodegenComponents.h:34: undefined
reference to `llvm::createSimpleRegisterAllocator()'
llvm2/include/llvm/CodeGen/LinkAllCodegenComponents.h:35: undefined
reference to `llvm::createLocalRegisterAllocator()'
llvm2/include/llvm/CodeGen/LinkAllCodegenComponents.h:36: undefined
reference to `llvm::createBigBlockRegisterAllocator()'
llvm2/include/llvm/CodeGen/LinkAllCodegenComponents.h:38: undefined
reference to `llvm::createPBQPRegisterAllocator()'
llvm2/include/llvm/CodeGen/LinkAllCodegenComponents.h:42: undefined
reference to `llvm::linkOcamlGC()'
llvm2/include/llvm/CodeGen/LinkAllCodegenComponents.h:43: undefined
reference to `llvm::linkShadowStackGC()'
/tmp/cc0b5iTo.o: In function `main':
VirementJit.cpp:110: undefined reference to
`llvm::sys::PrintStackTraceOnErrorSignal()'
VirementJit.cpp:122: undefined reference to
`llvm::getBitcodeModuleProvider(llvm::MemoryBuffer*,
std::basic_string,
std::allocator >*)'
/tmp/cc0b5iTo.o: In function `void
llvm::cl::opt_storage
true>::setValue,
std::allocator > >(std::basic_string
std::char_traits, std::allocator > const&)':
llvm2/include/llvm/Support/CommandLine.h:791: undefined reference
to `llvm::PluginLoader::operator=(std::basic_string
std::char_traits, std::allocator > const&)'
collect2: ld returned 1 exit status


What am I missing ?



Thanks

Hannibal

-- 
Be Yourself @ mail.com!
Choose From 200+ Email Addresses
Get a Free Account at www.mail.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090616/94482caa/attachment.html>

From granvillebarnett at googlemail.com  Tue Jun 16 05:59:42 2009
From: granvillebarnett at googlemail.com (Granville Barnett)
Date: Tue, 16 Jun 2009 13:59:42 +0100
Subject: [LLVMdev] Some understanding of LLVM vs gCC vs Intel C++
	Compilers
In-Reply-To: <200906160651.42044.jon@ffconsultancy.com>
References: <FAD2E372-2FC6-410E-9ECE-1AEAD896996D@MailNewsRSS.com>
	<fa28b9250906142332p27914ab3hb90ae6e93781884@mail.gmail.com>
	<200906151843.58729.dag@cray.com>
	<200906160651.42044.jon@ffconsultancy.com>
Message-ID: <80a70730906160559p369550f7qc24951ecfae67c0f@mail.gmail.com>

Are there any papers in the works which benchmark some specification suite
of C programs on GCC, LLVM-GCC, and CLANG?
The only stuff I have seen so far are some bar charts in a few LLVM
presentations, would be nice to have something a little more comprehensive.

Cheers,

Granville

On Tue, Jun 16, 2009 at 6:51 AM, Jon Harrop <jon at ffconsultancy.com> wrote:

> On Tuesday 16 June 2009 00:43:58 David Greene wrote:
> > But hey, we use LLVM to do it!
>
> Hello David,
>
> I just noticed your post and was wondering what Cray are doing with LLVM?
> Are
> you using it in production?
>
> I am trying to keep an eye on the fast moving LLVM project and like to keep
> up
> to date with respect to its industrial applications...
>
> --
> Dr Jon Harrop, Flying Frog Consultancy Ltd.
> http://www.ffconsultancy.com/?e
> _______________________________________________
> 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.llvm.org/pipermail/llvm-dev/attachments/20090616/1a803d3f/attachment.html>

From granvillebarnett at googlemail.com  Tue Jun 16 06:04:50 2009
From: granvillebarnett at googlemail.com (Granville Barnett)
Date: Tue, 16 Jun 2009 14:04:50 +0100
Subject: [LLVMdev] Tooling support for LLVM-GCC, or CLANG?
Message-ID: <80a70730906160604v5c7c2bd1n5813924a9d5ff691@mail.gmail.com>

Hi,
I seem to remember that a big point of LLVM being built with tooling support
out of the box was a major thing, however, I've not read anything about any
tools which are actually taking advantage of the foundation LLVM provides.
I'm not a Mac user, but I'd assume XCode would be a prime candidate -
does/will XCode use LLVMs foundation to create a better IDE experience?
Also, anyone know of similar efforts for Linux-based IDEs?

Cheers,

Granville
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090616/cd6f8b40/attachment.html>

From edwintorok at gmail.com  Tue Jun 16 07:27:17 2009
From: edwintorok at gmail.com (=?ISO-8859-15?Q?T=F6r=F6k_Edwin?=)
Date: Tue, 16 Jun 2009 17:27:17 +0300
Subject: [LLVMdev] undefined references in llvm
In-Reply-To: <20090616110516.AEE64326701@ws1-8.us4.outblaze.com>
References: <20090616110516.AEE64326701@ws1-8.us4.outblaze.com>
Message-ID: <4A37ABC5.3030309@gmail.com>

On 2009-06-16 14:05, hannibal hannibal wrote:
>
> Hello EveryOne,
>
> I am building customized tools for ARM using a crosscomplier. I am
> currently building a tool similar to lli but it only jits code. I
> enabled jit when I was configuring LLVM. On linking my code with
> help from llvm-config to the libraries I get this error:
>
> Can't exec "which": No such file or directory at
> llvm2/bin/llvm-config line 69.

I think you need the program called 'which'.


Best regards,
--Edwin


From aaronngray.lists at googlemail.com  Tue Jun 16 07:33:34 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Tue, 16 Jun 2009 15:33:34 +0100
Subject: [LLVMdev] Upcoming API change: FAdd, FSub, FMul
References: <BBF63352-A55A-4EF9-AB08-66B85AC6B841@apple.com>
Message-ID: <0AF43DF0F24D4CBEA428F7936A22024A@HPLAPTOP>


----- Original Message ----- 
From: "Dan Gohman" <gohman at apple.com>
To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
Sent: Tuesday, June 16, 2009 12:23 AM
Subject: [LLVMdev] Upcoming API change: FAdd, FSub, FMul


> Hello,
>
> The LLVM IR opcodes Add, Sub, and Mul have been each split into
> two.  Add, Sub, and Mul now only handle integer types, and three
> new opcodes, FAdd, FSub, and FMul now handle floating-point types.
>
> The main LLVM APIs are currently preserving backwards
> compatibility, transparently mapping integer opcodes to
> corresponding floating-point opcodes when the operands have
> floating-point types. This compatibility code will eventually be
> removed, so front-end writers should update their front-ends to
> use the new opcodes.  I've updated llvm-gcc as an example.
>
> As an aid to this process, the attached patch can be applied to a
> local LLVM tree to remove the backward-compatibility code, to
> allow front-ends to be tested.
>
>


--------------------------------------------------------------------------------


>
>
> Dan
>
>


--------------------------------------------------------------------------------


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



From aaronngray.lists at googlemail.com  Tue Jun 16 07:34:35 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Tue, 16 Jun 2009 15:34:35 +0100
Subject: [LLVMdev] Upcoming API change: FAdd, FSub, FMul
References: <BBF63352-A55A-4EF9-AB08-66B85AC6B841@apple.com>
Message-ID: <26C70595D1CA48D29F2B8CAB3E0FFA39@HPLAPTOP>

> The LLVM IR opcodes Add, Sub, and Mul have been each split into
> two.  Add, Sub, and Mul now only handle integer types, and three
> new opcodes, FAdd, FSub, and FMul now handle floating-point types.

Dan,

Wondering the reason why there is no FDiv ?

Thanks,

Aaron
  



From aaronngray.lists at googlemail.com  Tue Jun 16 07:44:04 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Tue, 16 Jun 2009 15:44:04 +0100
Subject: [LLVMdev] ML types in LLVM
References: <162de7480906130354m430f9e17ndbf03b41592ab982@mail.gmail.com><877hzfqjvu.fsf@mid.deneb.enyo.de><162de7480906140609y3c1f0584if03caa7bd993e43c@mail.gmail.com>
	<200906160658.42914.jon@ffconsultancy.com>
Message-ID: <863413A9B69F4C6584908938A3D2F2B9@HPLAPTOP>

>On Sunday 14 June 2009 14:09:33 Wesley W. Terpstra wrote:
>> On Sun, Jun 14, 2009 at 10:50 AM, Florian Weimer<fw at deneb.enyo.de> wrote:
>> > Is this really a problem for MLton? I think you only get less precise
>> > alias analysis, and that's it.
>>
>> Correct. However, I want a fair comparison between LLVM performance
>> and the native x86 codegen. If I don't give LLVM the same information
>> the x86 codegen has, it's an unfair comparison.
>
>Even if this puts LLVM at an unfair disadvantage, I think you will find 
>that
>LLVM will thrash MLton's current x86 backend anyway.
>
>I did some benchmarking on HLVM and found that it was often several times
>faster than OCaml when the GC is not the bottleneck:
>
>http://flyingfrogblog.blogspot.com/2009/03/performance-ocaml-vs-hlvm-beta-04.html

For numerical tasks and Array tasks but your graphs show for data 
manipulation for Lists LLVM is slower. I thnk you need further benchmarks, 
is this at all posible for you to do :)

Interesting,

Aaron



From aaronngray.lists at googlemail.com  Tue Jun 16 07:48:29 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Tue, 16 Jun 2009 15:48:29 +0100
Subject: [LLVMdev] x86 Intel Syntax and MASM 9.x
References: <D79A8D1CEFA38E45AD075F6EB49D9E8C0D53EFC6@sefsexmb1.amd.com>
	<f5aa3e9b0906151843g22b608a7u8397ee4854f17392@mail.gmail.com>
Message-ID: <512D8C46F5CB4E69AA3F8D99595A7CE2@HPLAPTOP>

>On Mon, Jun 15, 2009 at 5:49 PM, Gaster,
>Benedict<Benedict.Gaster at amd.com> wrote:
>> I would like to use the LLVM x86 code generator to emit Intel syntax that 
>> is
>> compatible with Microsoft’s MASM 9.x. Taking the TOT LLVM, from last 
>> week, I
>> have found a number of changes that are required to make this work, most 
>> of
>> which are straight forward but a couple I wanted to check with the group 
>> to
>> see what people thought was the best thing to do. In particular, I have 
>> made
>> all necessary changes and these are mostly constrained to the files:
>>
>> X86IntelAsmPrinter.[h|cpp]
>>
>> X86TargetAsmInfo.[h|cpp]
>
>Sounds good; did you mean to attach a patch?  It'll be easier to
>discuss with that.  (The output of "svn diff" is fine.)

Appently the GAS Intel backend has flaws and does not work correctly anyway 
so the X86IntelAsm backend is designed only to target MASM anyway.

Aaron





From gohman at apple.com  Tue Jun 16 07:49:40 2009
From: gohman at apple.com (Dan Gohman)
Date: Tue, 16 Jun 2009 07:49:40 -0700
Subject: [LLVMdev] Some understanding of LLVM vs gCC vs Intel
	C++	Compilers
In-Reply-To: <80a70730906160559p369550f7qc24951ecfae67c0f@mail.gmail.com>
References: <FAD2E372-2FC6-410E-9ECE-1AEAD896996D@MailNewsRSS.com>
	<fa28b9250906142332p27914ab3hb90ae6e93781884@mail.gmail.com>
	<200906151843.58729.dag@cray.com>
	<200906160651.42044.jon@ffconsultancy.com>
	<80a70730906160559p369550f7qc24951ecfae67c0f@mail.gmail.com>
Message-ID: <2216C982-A68A-4B14-B6A0-27B47D694733@apple.com>

Trying to capture a notion of overall compiler optimization
in a representative set of benchmarks is a hard problem.
If you're interested in performance, it's best to measure it
on the applications you're interested in.

You should be suspicious of any one-dimensional analysis
of compiler optimization, especially if it's presented by
someone with an interest in a particular compiler.

Dan

On Jun 16, 2009, at 5:59 AM, Granville Barnett wrote:

> Are there any papers in the works which benchmark some specification  
> suite of C programs on GCC, LLVM-GCC, and CLANG?
>
> The only stuff I have seen so far are some bar charts in a few LLVM  
> presentations, would be nice to have something a little more  
> comprehensive.
>
> Cheers,
>
> Granville
>
> On Tue, Jun 16, 2009 at 6:51 AM, Jon Harrop <jon at ffconsultancy.com>  
> wrote:
> On Tuesday 16 June 2009 00:43:58 David Greene wrote:
> > But hey, we use LLVM to do it!
>
> Hello David,
>
> I just noticed your post and was wondering what Cray are doing with  
> LLVM? Are
> you using it in production?
>
> I am trying to keep an eye on the fast moving LLVM project and like  
> to keep up
> to date with respect to its industrial applications...
>
> --
> Dr Jon Harrop, Flying Frog Consultancy Ltd.
> http://www.ffconsultancy.com/?e
> _______________________________________________
> 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  Tue Jun 16 07:49:47 2009
From: gohman at apple.com (Dan Gohman)
Date: Tue, 16 Jun 2009 07:49:47 -0700
Subject: [LLVMdev] Upcoming API change: FAdd, FSub, FMul
In-Reply-To: <26C70595D1CA48D29F2B8CAB3E0FFA39@HPLAPTOP>
References: <BBF63352-A55A-4EF9-AB08-66B85AC6B841@apple.com>
	<26C70595D1CA48D29F2B8CAB3E0FFA39@HPLAPTOP>
Message-ID: <B072C6DD-5782-4C74-BD72-1085BB96EA75@apple.com>


On Jun 16, 2009, at 7:34 AM, Aaron Gray wrote:

>> The LLVM IR opcodes Add, Sub, and Mul have been each split into
>> two.  Add, Sub, and Mul now only handle integer types, and three
>> new opcodes, FAdd, FSub, and FMul now handle floating-point types.
>
> Dan,
>
> Wondering the reason why there is no FDiv ?

FDiv already exists; div was split quite a while ago.

Dan



From cr88192 at hotmail.com  Tue Jun 16 08:18:49 2009
From: cr88192 at hotmail.com (BGB)
Date: Tue, 16 Jun 2009 08:18:49 -0700
Subject: [LLVMdev] Upcoming API change: FAdd, FSub, FMul
References: <BBF63352-A55A-4EF9-AB08-66B85AC6B841@apple.com><26C70595D1CA48D29F2B8CAB3E0FFA39@HPLAPTOP>
	<B072C6DD-5782-4C74-BD72-1085BB96EA75@apple.com>
Message-ID: <BLU0-SMTP815F9627D42B3447DA5FA5E43F0@phx.gbl>


----- Original Message ----- 
From: "Dan Gohman" <gohman at apple.com>
To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
Sent: Tuesday, June 16, 2009 7:49 AM
Subject: Re: [LLVMdev] Upcoming API change: FAdd, FSub, FMul


> 
> On Jun 16, 2009, at 7:34 AM, Aaron Gray wrote:
> 
>>> The LLVM IR opcodes Add, Sub, and Mul have been each split into
>>> two.  Add, Sub, and Mul now only handle integer types, and three
>>> new opcodes, FAdd, FSub, and FMul now handle floating-point types.
>>
>> Dan,
>>
>> Wondering the reason why there is no FDiv ?
> 
> FDiv already exists; div was split quite a while ago.
> 

just me wondering:
what is the reasoning behind this API change?...


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


From fvbommel at wxs.nl  Tue Jun 16 08:30:28 2009
From: fvbommel at wxs.nl (Frits van Bommel)
Date: Tue, 16 Jun 2009 17:30:28 +0200
Subject: [LLVMdev] Upcoming API change: FAdd, FSub, FMul
In-Reply-To: <26C70595D1CA48D29F2B8CAB3E0FFA39@HPLAPTOP>
References: <BBF63352-A55A-4EF9-AB08-66B85AC6B841@apple.com>
	<26C70595D1CA48D29F2B8CAB3E0FFA39@HPLAPTOP>
Message-ID: <4A37BA94.7050800@wxs.nl>

Aaron Gray wrote:
>> The LLVM IR opcodes Add, Sub, and Mul have been each split into
>> two.  Add, Sub, and Mul now only handle integer types, and three
>> new opcodes, FAdd, FSub, and FMul now handle floating-point types.
> 
> Dan,
> 
> Wondering the reason why there is no FDiv ?

It already existed, and still does: http://llvm.org/docs/LangRef.html#i_fdiv


From hannibal_08 at mail.com  Tue Jun 16 08:39:44 2009
From: hannibal_08 at mail.com (hannibal hannibal)
Date: Tue, 16 Jun 2009 10:39:44 -0500
Subject: [LLVMdev] undefined references in llvm
Message-ID: <20090616153944.358E0BE4082@ws1-9.us4.outblaze.com>

llvm-config can now find 'which' but I still get the same error.



Thanks 

hannibal

----- Original Message -----
From: "Török Edwin" 
To: "LLVM Developers Mailing List" 
Subject: Re: [LLVMdev] undefined references in llvm
Date: Tue, 16 Jun 2009 17:27:17 +0300


On 2009-06-16 14:05, hannibal hannibal wrote:
>
> Hello EveryOne,
>
> I am building customized tools for ARM using a crosscomplier. I am
> currently building a tool similar to lli but it only jits code. I
> enabled jit when I was configuring LLVM. On linking my code with
> help from llvm-config to the libraries I get this error:
>
> Can't exec "which": No such file or directory at
> llvm2/bin/llvm-config line 69.

I think you need the program called 'which'.


Best regards,
--Edwin
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


-- 
Be Yourself @ mail.com!
Choose From 200+ Email Addresses
Get a Free Account at www.mail.com




From sanjiv.gupta at microchip.com  Tue Jun 16 08:38:54 2009
From: sanjiv.gupta at microchip.com (Sanjiv Gupta)
Date: Tue, 16 Jun 2009 21:08:54 +0530
Subject: [LLVMdev] Localizing Globals ?
In-Reply-To: <f5aa3e9b0906160310y223ae6d7ve0842397b7f2594c@mail.gmail.com>
References: <4A376756.9010302@microchip.com>
	<f5aa3e9b0906160310y223ae6d7ve0842397b7f2594c@mail.gmail.com>
Message-ID: <4A37BC8E.3090208@microchip.com>

Eli Friedman wrote:
> On Tue, Jun 16, 2009 at 2:35 AM, Sanjiv Gupta<sanjiv.gupta at microchip.com> wrote:
>   
>> What if my global variable was into a different address space than stack?
>>     
>
> It doesn't matter in terms of semantics: because AnalyzeGlobal
> returned false, we're guaranteed the address of the global is never
> taken.  I wouldn't be surprised if we end up generating invalid IR in
> some cases, though, because of the semantics of replaceAllUsesWith.
> Do you have a testcase that breaks?
>
>   
I do not really have a test case. I came across this when llvm-ld 
crashed while working with the debug information after such optimization.
>> How do I deny this optimization in that case? Can I find address space
>> for stack from AllocaInst and then compare the address spaces for two?
>>     
>
> An alloca is guaranteed to be in address space zero, so you can just
> check something like "GV->getType()->getAddressSpace() == 0".
>
> -Eli
>   
As you should, this check shouldn't be required semantically as the 
address is never taken, I would like to investigate more as to why 
llvm-ld crashed on the debug info.

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



From sanjiv.gupta at microchip.com  Tue Jun 16 09:26:29 2009
From: sanjiv.gupta at microchip.com (Sanjiv Gupta)
Date: Tue, 16 Jun 2009 21:56:29 +0530
Subject: [LLVMdev] [Fwd: buildbot failure in llvm on llvm-ppc-linux]
Message-ID: <4A37C7B5.7060104@microchip.com>


I don't know what failed on llvm-ppc-linux.  The build works on my 
i386-linux.
I can't access the said URL. It says "connection refused".

- Sanjiv

-------- Original Message --------
Subject: 	buildbot failure in llvm on llvm-ppc-linux
Date: 	Tue, 16 Jun 2009 09:20:25 -0700
From: 	buildbot at google1.osuosl.org
To: 	Sanjiv Gupta <sanjiv.gupta at microchip.com>
CC: 	llvm-testresults at cs.uiuc.edu



The Buildbot has detected a new failure of llvm-ppc-linux on llvm.
Full details are available at:
 http://google1.osuosl.org:8011/builders/llvm-ppc-linux/builds/2002

Buildbot URL: http://google1.osuosl.org:8011/

Buildslave for this Build: nick1

Build Reason: 
Build Source Stamp: 73491
Blamelist: sgupta

BUILD FAILED: failed svn

sincerely,
 -The Buildbot




From edwintorok at gmail.com  Tue Jun 16 09:39:48 2009
From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=)
Date: Tue, 16 Jun 2009 19:39:48 +0300
Subject: [LLVMdev] [Fwd: buildbot failure in llvm on llvm-ppc-linux]
In-Reply-To: <4A37C7B5.7060104@microchip.com>
References: <4A37C7B5.7060104@microchip.com>
Message-ID: <4A37CAD4.50505@gmail.com>

On 2009-06-16 19:26, Sanjiv Gupta wrote:
> I don't know what failed on llvm-ppc-linux.  The build works on my 
> i386-linux.
> I can't access the said URL. It says "connection refused".
>
>   

Works from here, it says SVN checkout failed.
I think its that buildbot bug again.

Is usepty set to 0 in this buildslave's buildbot.tac?

Best regards,
--Edwin


From Benedict.Gaster at amd.com  Tue Jun 16 09:39:29 2009
From: Benedict.Gaster at amd.com (Gaster, Benedict)
Date: Tue, 16 Jun 2009 18:39:29 +0200
Subject: [LLVMdev] x86 Intel Syntax and MASM 9.x
In-Reply-To: <f5aa3e9b0906160009v37c61ca2q125522caf59b77df@mail.gmail.com>
References: <D79A8D1CEFA38E45AD075F6EB49D9E8C0D53EFC6@sefsexmb1.amd.com><f5aa3e9b0906151843g22b608a7u8397ee4854f17392@mail.gmail.com><D79A8D1CEFA38E45AD075F6EB49D9E8C0D53F004@sefsexmb1.amd.com>
	<f5aa3e9b0906160009v37c61ca2q125522caf59b77df@mail.gmail.com>
Message-ID: <D79A8D1CEFA38E45AD075F6EB49D9E8C0D53F2EF@sefsexmb1.amd.com>

Hi Eli,

Yep I was being stupid.

Please find attached a patch for initial changes to get MASM working.

There is still one problem that I am looking into around changing
alignments within SEGMENTS. The problem is that MASM allows 2,4,16,256
alignments, default being 16, but LLVM is sometimes generating 32
alignment, for example, consider the following code: 

float bar(float fy, float fx)
{
  static const double foo[  241] = {
    6.24188099959573430842e-02,  
    6.63088949198234745008e-02,  
  }
}

Is generating the data segment:

_data   segment PARA 'DATA'
__2E_str:                               ; .str
        db 'out',0
__2E_str1:                              ; .str1
        db 'in',0
        public ___some_other_sruct_data
        ALIGN   4
___some_other_sruct_data:               ; 
       dd      7                       ; 0x7
       dd      3                       ; 0x3
       dd      __2E_str
       db      12 dup(0)
       dd      7                       ; 0x7
       dd      3                       ; 0x3
       dd      __2E_str1
       db      12 dup(0)
       db      12 dup(0)
sgv:                           ; sgv
       db      1 dup(0)
       ALIGN   4
lvgv:                          ; lvgv
       ALIGN   32
foo:                           ; 
        dq      4589156319577832937     ; double value: 6.241881e-002
        dq      4589442480094401190     ; double value: 6.630889e-002

MASM reports the following error:

error A2189:invalid combination with segment alignment : 32

Regards,

Ben

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
On Behalf Of Eli Friedman
Sent: Tuesday, June 16, 2009 12:10 AM
To: LLVM Developers Mailing List
Subject: Re: [LLVMdev] x86 Intel Syntax and MASM 9.x

On Mon, Jun 15, 2009 at 11:21 PM, Gaster,
Benedict<Benedict.Gaster at amd.com> wrote:
> I can get this two work with additional changes to X86InstrInfocpp but
> the problem I have with this approach is that it introduces a lot of
> duplication, when all I really want to do is parameterize the final
> field in the string "shl{b}\t{%cl, $dst|$dst, %CL}". I was wondering
> (hoping :-) if you knew of a better method to handling this?

I think you're missing the whole point of the "|" construct; the left
side is AT&T syntax, the right side is Intel syntax.

-Eli
_______________________________________________
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: masm.patch
Type: application/octet-stream
Size: 15767 bytes
Desc: masm.patch
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090616/691a2731/attachment.obj>

From aaronngray.lists at googlemail.com  Tue Jun 16 09:50:56 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Tue, 16 Jun 2009 17:50:56 +0100
Subject: [LLVMdev] Upcoming API change: FAdd, FSub, FMul
References: <BBF63352-A55A-4EF9-AB08-66B85AC6B841@apple.com><26C70595D1CA48D29F2B8CAB3E0FFA39@HPLAPTOP>
	<B072C6DD-5782-4C74-BD72-1085BB96EA75@apple.com>
Message-ID: <4E09C7FC844B485F90436F264D07CEB6@HPLAPTOP>

> On Jun 16, 2009, at 7:34 AM, Aaron Gray wrote:
> 
>>> The LLVM IR opcodes Add, Sub, and Mul have been each split into
>>> two.  Add, Sub, and Mul now only handle integer types, and three
>>> new opcodes, FAdd, FSub, and FMul now handle floating-point types.
>>
>> Dan,
>>
>> Wondering the reason why there is no FDiv ?
> 
> FDiv already exists; div was split quite a while ago.

Ah, right I must have missed its introduction.

Thanks,

Aaron



From gohman at apple.com  Tue Jun 16 10:00:18 2009
From: gohman at apple.com (Dan Gohman)
Date: Tue, 16 Jun 2009 10:00:18 -0700
Subject: [LLVMdev] Upcoming API change: FAdd, FSub, FMul
In-Reply-To: <BLU0-SMTP815F9627D42B3447DA5FA5E43F0@phx.gbl>
References: <BBF63352-A55A-4EF9-AB08-66B85AC6B841@apple.com>
	<26C70595D1CA48D29F2B8CAB3E0FFA39@HPLAPTOP>
	<B072C6DD-5782-4C74-BD72-1085BB96EA75@apple.com>
	<BLU0-SMTP815F9627D42B3447DA5FA5E43F0@phx.gbl>
Message-ID: <6A10F283-B031-4B12-81D4-CCD0238302BF@apple.com>


On Jun 16, 2009, at 8:18 AM, BGB wrote:
>
> just me wondering:
> what is the reasoning behind this API change?...

It makes the IR a little more consistent, and it's the first
step to implement the functionality outlined here:

http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt

Also, some day the floating-point instructions will likely be
extended with floating-point-specific flags.

Dan



From victor.zverovich at googlemail.com  Tue Jun 16 09:57:54 2009
From: victor.zverovich at googlemail.com (Victor Zverovich)
Date: Tue, 16 Jun 2009 17:57:54 +0100
Subject: [LLVMdev] runtime library for jitted code
In-Reply-To: <87ski1cxbl.fsf@telefonica.net>
References: <a88d534c0906150235w6f0e3ce3i4302f4eeae6b03d0@mail.gmail.com>
	<4A365D35.3040005@t-online.de> <87ski1cxbl.fsf@telefonica.net>
Message-ID: <a88d534c0906160957n58ae9efdqcaeb5fb3ee38da5@mail.gmail.com>

Hi,
The question about the name mangling gave me an idea that it can be used to
automate registration of DLL functions. Instead of manually creating
Function objects specifying a return type and argument types which is
error-prone and time-consuming one can get a list of functions exported from
a DLL using Windows API, demangle each name and construct a Function object
from it. Is there any support for Visual C++ style (de)mangling in LLVM or
related project? In any case I think it won't be difficult for me to write
such a converter from mangled names to LLVM function declarations.

Best regards,
Victor

2009/6/15 Óscar Fuentes <ofv at wanadoo.es>

> Albert Graef <Dr.Graef at t-online.de> writes:
>
> > Victor Zverovich wrote:
> >> I am considering a possibility of using LLVM JIT for an algebraic
> >> modelling language. I have already done some prototyping following the
> >> Kaleidoscope tutorial and currently thinking of how to connect the
> >> jitted code to a runtime library (for this language) which I would like
> >> to code in C++. If it was *NIX I would use g++ possibly with '-rdynamic'
> >> option as suggested in the tutorial to resolve required functions at
> >> runtime. However it is not an option, I am stuck to Windows and Visual
> >> C++.
> >
> > Well, backlinking doesn't work on Windows, but you can create a dll for
> > your runtime and use LLVM's dynamic library interface to load that dll.
> > I'm doing it that way in my project (http://pure-lang.googlecode.com/,
> > search for 'sys::DynamicLibrary::' in interpreter.cc) and it works fine
> > on Windows.
>
> The OP says that he wants to link to a dll coded in C++. Isn't name
> mangling the main problem here?
>
> --
> Óscar
>
> _______________________________________________
> 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.llvm.org/pipermail/llvm-dev/attachments/20090616/06c8d420/attachment.html>

From tonic at nondot.org  Tue Jun 16 10:56:12 2009
From: tonic at nondot.org (Tanya M. Lattner)
Date: Tue, 16 Jun 2009 10:56:12 -0700 (PDT)
Subject: [LLVMdev] 2.6 Release schedule
Message-ID: <alpine.DEB.2.00.0906161045100.12292@nondot.org>


I apologize for the delay in setting the 2.6 schedule. Please be aware 
that we are now moving to a ~6 month release cycle. In addition, 2.6 will 
be our first release that includes Clang.

08/21 - Code freeze
08/28 - Pre-release1 testing begins
09/04 - Pre-release1 testing ends
09/11 - Pre-release2 testing begins
09/18 - Pre-release2 testing ends
09/21 - Release 2.6

For those that emailed me about being a part of the llvm release team, I 
will be emailing you soon to confirm that you still want to volunteer and 
with more details on what this release process will entail.

If you have any questions, please do not hesitate to ask.

Thanks,
Tanya Lattner


From resistor at mac.com  Tue Jun 16 11:03:25 2009
From: resistor at mac.com (Owen Anderson)
Date: Tue, 16 Jun 2009 11:03:25 -0700
Subject: [LLVMdev] UPCOMING API CHANGE: Threads and LLVM
In-Reply-To: <BB9EB6C4-21F6-47BA-BD49-AAE755D07946@mac.com>
References: <BB9EB6C4-21F6-47BA-BD49-AAE755D07946@mac.com>
Message-ID: <83AABF09-32DA-44C4-BCDA-3EA218E77637@mac.com>

On Jun 15, 2009, at 6:16 PM, Owen Anderson wrote:
> The major CHANGE is:  the JIT will no longer be safe for executing
> threaded applications without first invoking llvm_start_multithreaded
> ().  Please begin to update your client applications now if this
> affects you, as I will be throwing the switch in SVN sooner rather
> than later.

After some further reflection on this point, I don't think it will be  
necessary to make llvm_start_multithreaded() strictly required for all  
applications that want to host threaded applications in the JIT.  It  
is, however, strongly recommended, especially if you're using side  
exits, to guard against to possibility of accidental concurrent calls  
into the LLVM API.

I still welcome any comments, particular from VM implementers.

--Owen


From Joseph.Blomstedt at colorado.edu  Tue Jun 16 11:07:50 2009
From: Joseph.Blomstedt at colorado.edu (Joseph Blomstedt)
Date: Tue, 16 Jun 2009 13:07:50 -0500
Subject: [LLVMdev] runtime library for jitted code
In-Reply-To: <a88d534c0906160957n58ae9efdqcaeb5fb3ee38da5@mail.gmail.com>
References: <a88d534c0906150235w6f0e3ce3i4302f4eeae6b03d0@mail.gmail.com>
	<4A365D35.3040005@t-online.de> <87ski1cxbl.fsf@telefonica.net>
	<a88d534c0906160957n58ae9efdqcaeb5fb3ee38da5@mail.gmail.com>
Message-ID: <ab5941020906161107x16dd0c7eyc0f349f8967b1d9f@mail.gmail.com>

If you're simply looking to write a generator that spits out LLVM code
that you can link into your language, you should be able to throw
together something that uses the "undname.exe" utility from Visual
Studio that demangles all the names listed in a provided file.
Something like a script that's part of your build process and
generates the necessary stub code to link in by using dumpbin and
undname.

If you're interested in doing this "on the fly" during JIT for some
reason, there's the Microsoft APIs UnDecorateSymbolName and _unDName.
The first is a publicly documented API, the second is internal but
more feature rich. An Internet search should provide insight into
these. There's also open-source Wine code for _unDName I believe.


On Tue, Jun 16, 2009 at 11:57 AM, Victor
Zverovich<victor.zverovich at googlemail.com> wrote:
> Hi,
> The question about the name mangling gave me an idea that it can be used to
> automate registration of DLL functions. Instead of manually creating
> Function objects specifying a return type and argument types which is
> error-prone and time-consuming one can get a list of functions exported from
> a DLL using Windows API, demangle each name and construct a Function object
> from it. Is there any support for Visual C++ style (de)mangling in LLVM or
> related project? In any case I think it won't be difficult for me to write
> such a converter from mangled names to LLVM function declarations.
> Best regards,
> Victor


From anton at korobeynikov.info  Tue Jun 16 11:15:27 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Tue, 16 Jun 2009 22:15:27 +0400
Subject: [LLVMdev] x86 Intel Syntax and MASM 9.x
In-Reply-To: <D79A8D1CEFA38E45AD075F6EB49D9E8C0D53F2EF@sefsexmb1.amd.com>
References: <D79A8D1CEFA38E45AD075F6EB49D9E8C0D53EFC6@sefsexmb1.amd.com>
	<f5aa3e9b0906151843g22b608a7u8397ee4854f17392@mail.gmail.com>
	<D79A8D1CEFA38E45AD075F6EB49D9E8C0D53F004@sefsexmb1.amd.com>
	<f5aa3e9b0906160009v37c61ca2q125522caf59b77df@mail.gmail.com>
	<D79A8D1CEFA38E45AD075F6EB49D9E8C0D53F2EF@sefsexmb1.amd.com>
Message-ID: <1245176127.30739.21.camel@aslstation>

Hello, Benedict

> There is still one problem that I am looking into around changing
> alignments within SEGMENTS. The problem is that MASM allows 2,4,16,256
> alignments, default being 16, but LLVM is sometimes generating 32
> alignment, for example, consider the following code: 
That's correct. MASM is too weak to represent even slightly non-trivial
program. In your particular case - LLVM IR can set up any alignment it
want. Also note the FIXME's in the X86IntelAsmPrinter.cpp wrt the
alignment. 

You might try to round up the alignment to the highest allowed value,
but this might be an overkill...

-- 
With best regards, Anton Korobeynikov.

Faculty of Mathematics & Mechanics, Saint Petersburg State University.



From eli.friedman at gmail.com  Tue Jun 16 11:18:32 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Tue, 16 Jun 2009 11:18:32 -0700
Subject: [LLVMdev] x86 Intel Syntax and MASM 9.x
In-Reply-To: <D79A8D1CEFA38E45AD075F6EB49D9E8C0D53F2EF@sefsexmb1.amd.com>
References: <D79A8D1CEFA38E45AD075F6EB49D9E8C0D53EFC6@sefsexmb1.amd.com>
	<f5aa3e9b0906151843g22b608a7u8397ee4854f17392@mail.gmail.com>
	<D79A8D1CEFA38E45AD075F6EB49D9E8C0D53F004@sefsexmb1.amd.com>
	<f5aa3e9b0906160009v37c61ca2q125522caf59b77df@mail.gmail.com>
	<D79A8D1CEFA38E45AD075F6EB49D9E8C0D53F2EF@sefsexmb1.amd.com>
Message-ID: <f5aa3e9b0906161118j525c09c4o1a06a4e6b2a83e8@mail.gmail.com>

On Tue, Jun 16, 2009 at 9:39 AM, Gaster,
Benedict<Benedict.Gaster at amd.com> wrote:
> Hi Eli,
>
> Yep I was being stupid.
>
> Please find attached a patch for initial changes to get MASM working.

Patch looks fine except that it has tabs (LLVM uses only spaces for
indentation).  Also, can you generate the patch using "svn diff"?
It's currently in some unusual format which "patch" doesn't recognize.

> There is still one problem that I am looking into around changing
> alignments within SEGMENTS. The problem is that MASM allows 2,4,16,256
> alignments, default being 16, but LLVM is sometimes generating 32
> alignment, for example, consider the following code:

Huh.  For correctness, I guess you'll have to round up the alignment,
and abort on anything higher than 256.  (Also, perhaps the front-end
should avoid generating such constructs in the first place when
targeting Windows, but that's a separate issue.)

-Eli


From Benedict.Gaster at amd.com  Tue Jun 16 11:28:48 2009
From: Benedict.Gaster at amd.com (Gaster, Benedict)
Date: Tue, 16 Jun 2009 20:28:48 +0200
Subject: [LLVMdev] x86 Intel Syntax and MASM 9.x
In-Reply-To: <1245176127.30739.21.camel@aslstation>
References: <D79A8D1CEFA38E45AD075F6EB49D9E8C0D53EFC6@sefsexmb1.amd.com><f5aa3e9b0906151843g22b608a7u8397ee4854f17392@mail.gmail.com><D79A8D1CEFA38E45AD075F6EB49D9E8C0D53F004@sefsexmb1.amd.com><f5aa3e9b0906160009v37c61ca2q125522caf59b77df@mail.gmail.com><D79A8D1CEFA38E45AD075F6EB49D9E8C0D53F2EF@sefsexmb1.amd.com>
	<1245176127.30739.21.camel@aslstation>
Message-ID: <D79A8D1CEFA38E45AD075F6EB49D9E8C0D53F316@sefsexmb1.amd.com>

Hi Anton,

Indeed your work around of rounding up to supported alignment is what I
have implemented but it was not clear to me that this should be
submitted back. As you point out as there are many other FIXMEs with the
X86IntelAsmPrinter maybe this is the "fix" for now.

Regards,

Ben

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
On Behalf Of Anton Korobeynikov
Sent: Tuesday, June 16, 2009 11:15 AM
To: LLVM Developers Mailing List
Subject: Re: [LLVMdev] x86 Intel Syntax and MASM 9.x

Hello, Benedict

> There is still one problem that I am looking into around changing
> alignments within SEGMENTS. The problem is that MASM allows 2,4,16,256
> alignments, default being 16, but LLVM is sometimes generating 32
> alignment, for example, consider the following code: 
That's correct. MASM is too weak to represent even slightly non-trivial
program. In your particular case - LLVM IR can set up any alignment it
want. Also note the FIXME's in the X86IntelAsmPrinter.cpp wrt the
alignment. 

You might try to round up the alignment to the highest allowed value,
but this might be an overkill...

-- 
With best regards, Anton Korobeynikov.

Faculty of Mathematics & 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





From isanbard at gmail.com  Tue Jun 16 11:47:21 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Tue, 16 Jun 2009 11:47:21 -0700
Subject: [LLVMdev] Tooling support for LLVM-GCC, or CLANG?
In-Reply-To: <80a70730906160604v5c7c2bd1n5813924a9d5ff691@mail.gmail.com>
References: <80a70730906160604v5c7c2bd1n5813924a9d5ff691@mail.gmail.com>
Message-ID: <16e5fdf90906161147k246b36b4o5e0cfeba3efe0b18@mail.gmail.com>

On Tue, Jun 16, 2009 at 6:04 AM, Granville
Barnett<granvillebarnett at googlemail.com> wrote:
> Hi,
> I seem to remember that a big point of LLVM being built with tooling support
> out of the box was a major thing, however, I've not read anything about any
> tools which are actually taking advantage of the foundation LLVM provides.
> I'm not a Mac user, but I'd assume XCode would be a prime candidate -
> does/will XCode use LLVMs foundation to create a better IDE experience?
> Also, anyone know of similar efforts for Linux-based IDEs?

Hi Granville,

Clang itself takes advantage of the LLVM libraries
(http://clang.llvm.org/). The static analyzer takes advantage of the
clang libraries (same URL). There are a host of tools in the tools/
sub-directory, which all use the LLVM libraries.

:-)

-bw


From anton at korobeynikov.info  Tue Jun 16 11:59:27 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Tue, 16 Jun 2009 22:59:27 +0400
Subject: [LLVMdev] x86 Intel Syntax and MASM 9.x
In-Reply-To: <f5aa3e9b0906161118j525c09c4o1a06a4e6b2a83e8@mail.gmail.com>
References: <D79A8D1CEFA38E45AD075F6EB49D9E8C0D53EFC6@sefsexmb1.amd.com>
	<f5aa3e9b0906151843g22b608a7u8397ee4854f17392@mail.gmail.com>
	<D79A8D1CEFA38E45AD075F6EB49D9E8C0D53F004@sefsexmb1.amd.com>
	<f5aa3e9b0906160009v37c61ca2q125522caf59b77df@mail.gmail.com>
	<D79A8D1CEFA38E45AD075F6EB49D9E8C0D53F2EF@sefsexmb1.amd.com>
	<f5aa3e9b0906161118j525c09c4o1a06a4e6b2a83e8@mail.gmail.com>
Message-ID: <b087fca00906161159x641c9cf1j1ce985c1b1a6402c@mail.gmail.com>

Hi, Eli

> Huh.  For correctness, I guess you'll have to round up the alignment,
> and abort on anything higher than 256.  (Also, perhaps the front-end
> should avoid generating such constructs in the first place when
> targeting Windows, but that's a separate issue.)
It depends on frontend :) I don't see why, for example, llvm-gcc for
mingw32 should not generate such globals. Everything is perfect with
gas. Also, for example, masm does not support weak symbols which is a
requirement for more or less non-trivial C++ code

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



From Benedict.Gaster at amd.com  Tue Jun 16 12:18:47 2009
From: Benedict.Gaster at amd.com (Gaster, Benedict)
Date: Tue, 16 Jun 2009 21:18:47 +0200
Subject: [LLVMdev] x86 Intel Syntax and MASM 9.x
In-Reply-To: <f5aa3e9b0906161118j525c09c4o1a06a4e6b2a83e8@mail.gmail.com>
References: <D79A8D1CEFA38E45AD075F6EB49D9E8C0D53EFC6@sefsexmb1.amd.com><f5aa3e9b0906151843g22b608a7u8397ee4854f17392@mail.gmail.com><D79A8D1CEFA38E45AD075F6EB49D9E8C0D53F004@sefsexmb1.amd.com><f5aa3e9b0906160009v37c61ca2q125522caf59b77df@mail.gmail.com><D79A8D1CEFA38E45AD075F6EB49D9E8C0D53F2EF@sefsexmb1.amd.com>
	<f5aa3e9b0906161118j525c09c4o1a06a4e6b2a83e8@mail.gmail.com>
Message-ID: <D79A8D1CEFA38E45AD075F6EB49D9E8C0D53F329@sefsexmb1.amd.com>

Hi Eli,

Sorry about that Visual Studio seems to have inserted tabs and I used an
internal diff tool. Anyway, I synced TOT LLVM and made the changes with
Emacs and the svn diff is attached.

Regards,

Ben

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
On Behalf Of Eli Friedman
Sent: Tuesday, June 16, 2009 11:19 AM
To: LLVM Developers Mailing List
Subject: Re: [LLVMdev] x86 Intel Syntax and MASM 9.x

On Tue, Jun 16, 2009 at 9:39 AM, Gaster,
Benedict<Benedict.Gaster at amd.com> wrote:
> Hi Eli,
>
> Yep I was being stupid.
>
> Please find attached a patch for initial changes to get MASM working.

Patch looks fine except that it has tabs (LLVM uses only spaces for
indentation).  Also, can you generate the patch using "svn diff"?
It's currently in some unusual format which "patch" doesn't recognize.

> There is still one problem that I am looking into around changing
> alignments within SEGMENTS. The problem is that MASM allows 2,4,16,256
> alignments, default being 16, but LLVM is sometimes generating 32
> alignment, for example, consider the following code:

Huh.  For correctness, I guess you'll have to round up the alignment,
and abort on anything higher than 256.  (Also, perhaps the front-end
should avoid generating such constructs in the first place when
targeting Windows, but that's a separate issue.)

-Eli
_______________________________________________
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: masm.diff
Type: application/octet-stream
Size: 14450 bytes
Desc: masm.diff
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090616/dce8d0f6/attachment.obj>

From aaronngray.lists at googlemail.com  Tue Jun 16 12:40:37 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Tue, 16 Jun 2009 20:40:37 +0100
Subject: [LLVMdev] PIC documentation ?
In-Reply-To: <b087fca00906142127n55bcaa7bi729be3d6c2e9ae56@mail.gmail.com>
References: <8653927FD91A400AB077D2EF48F7132D@HPLAPTOP>
	<b087fca00906142127n55bcaa7bi729be3d6c2e9ae56@mail.gmail.com>
Message-ID: <9719867c0906161240s428a8569ub0d0a453faa9d679@mail.gmail.com>

Anton,

Sorry I have not replied earlier.

Can I ask what platform ABI's are documented other than Itanium ?

I need to get to understand PIC on x86, x86_64 and PowerPC for the COFF and
MachO backends.

Thanks,

Aaron



2009/6/15 Anton Korobeynikov <anton at korobeynikov.info>

> Hello, Aaron
>
> > Is there any overview or detailed socumentation on LLVM PIC ?
> Did you mean Position Independent Code? If so - there is nothing
> special here, LLVM just implements (when this is implemented) what is
> defined in platform ABI.
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090616/aa30d65f/attachment.html>

From andrelct at dcc.ufmg.br  Tue Jun 16 12:55:01 2009
From: andrelct at dcc.ufmg.br (Andre Tavares)
Date: Tue, 16 Jun 2009 16:55:01 -0300
Subject: [LLVMdev] SSI and ABCD for LLVM
In-Reply-To: <16517D08-D112-4764-9FE6-91B37DE26857@cs.uiuc.edu>
References: <4A27D078.807@dcc.ufmg.br>
	<4A28170A.3020204@lip6.fr>	<1244161343.3936.1.camel@haohui-laptop>	<4A2875E3.9070706@dcc.ufmg.br>	<4a292afe.04015a0a.5436.2327@mx.google.com>
	<16517D08-D112-4764-9FE6-91B37DE26857@cs.uiuc.edu>
Message-ID: <4A37F895.5080209@dcc.ufmg.br>

Vikram S. Adve wrote:
> On Jun 5, 2009, at 9:26 AM, Mai, Haohui wrote:
>
>   
>> By static array bounds checking, I mean eliminating array bounds  
>> checking
>> which can be proved ``safe'' at compile-time.
>>     
>
> Even though SAFECode does have such a pass, there are some tradeoffs  
> with the current version:
>
> 1. It uses an external solver (Omega), which is one more dependence  
> for LLVM in general.  I don't have a problem with this myself but some  
> users may.
>
> 2. The existing algorithm for propagating constraints (inequalities)  
> on variables is interprocedural (good) and inefficient (bad).
>
> ABCD has different tradeoffs.  IIRC, ABCD doesn't use an external  
> solver, though only because it only handles simple sets of  
> inequalities.  The original ABCD algorithm is also intraprocedural,  
> which seems extremely limiting in practice.  Is there any plan of  
> extending this to work interprocedurally?
>
> --Vikram
> Associate Professor, Computer Science
> University of Illinois at Urbana-Champaign
> http://llvm.org/~vadve
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>   
Dear Vikram,

we chose ABCD because it is a fast approach to solve the problem. It has 
the drawback that it is intra-procedural. For the Summer of Code 
project, we will stick to the original ABCD algorithm. But we can study 
modifications to make it inter-procedural for later research. Any ideas 
and contributions you might have will be welcome.

-- 
Andre Tavares
Master Student in Computer Science - UFMG - Brasil
http://dcc.ufmg.br/~andrelct



From granvillebarnett at googlemail.com  Tue Jun 16 13:05:13 2009
From: granvillebarnett at googlemail.com (Granville Barnett)
Date: Tue, 16 Jun 2009 21:05:13 +0100
Subject: [LLVMdev] Tooling support for LLVM-GCC, or CLANG?
In-Reply-To: <16e5fdf90906161147k246b36b4o5e0cfeba3efe0b18@mail.gmail.com>
References: <80a70730906160604v5c7c2bd1n5813924a9d5ff691@mail.gmail.com>
	<16e5fdf90906161147k246b36b4o5e0cfeba3efe0b18@mail.gmail.com>
Message-ID: <80a70730906161305j1e12e73ep80d9d774907c22c3@mail.gmail.com>

I'm more interested in whether or not there are any projects in the works
that fuse the tools together to build a better IDE experience. I forget
which presentation it was, but one of the developers (I *think* it was the
gentleman that presented something on CLANG at the dev's conference 2008)
made a bit of a point by saying that LLVM, unlike GCC has been built from
the ground up with tooling in mind. I appreciate that the tools that ship
with LLVM use the foundation in place, however, I am curious as to whether
there are any IDE projects that are building further upon this.
Granville

On Tue, Jun 16, 2009 at 7:47 PM, Bill Wendling <isanbard at gmail.com> wrote:

> On Tue, Jun 16, 2009 at 6:04 AM, Granville
> Barnett<granvillebarnett at googlemail.com> wrote:
> > Hi,
> > I seem to remember that a big point of LLVM being built with tooling
> support
> > out of the box was a major thing, however, I've not read anything about
> any
> > tools which are actually taking advantage of the foundation LLVM
> provides.
> > I'm not a Mac user, but I'd assume XCode would be a prime candidate -
> > does/will XCode use LLVMs foundation to create a better IDE experience?
> > Also, anyone know of similar efforts for Linux-based IDEs?
>
> Hi Granville,
>
> Clang itself takes advantage of the LLVM libraries
> (http://clang.llvm.org/). The static analyzer takes advantage of the
> clang libraries (same URL). There are a host of tools in the tools/
> sub-directory, which all use the LLVM libraries.
>
> :-)
>
> -bw
> _______________________________________________
> 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.llvm.org/pipermail/llvm-dev/attachments/20090616/65a029d0/attachment.html>

From ofv at wanadoo.es  Tue Jun 16 13:07:40 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Tue, 16 Jun 2009 22:07:40 +0200
Subject: [LLVMdev] runtime library for jitted code
References: <a88d534c0906150235w6f0e3ce3i4302f4eeae6b03d0@mail.gmail.com>
	<4A365D35.3040005@t-online.de> <87ski1cxbl.fsf@telefonica.net>
	<a88d534c0906160957n58ae9efdqcaeb5fb3ee38da5@mail.gmail.com>
Message-ID: <87ocsoc583.fsf@telefonica.net>

Victor Zverovich <victor.zverovich at googlemail.com> writes:

> The question about the name mangling gave me an idea that it can be used to
> automate registration of DLL functions. Instead of manually creating
> Function objects specifying a return type and argument types which is
> error-prone and time-consuming one can get a list of functions exported from
> a DLL using Windows API, demangle each name and construct a Function object
> from it. Is there any support for Visual C++ style (de)mangling in LLVM or
> related project? In any case I think it won't be difficult for me to write
> such a converter from mangled names to LLVM function declarations.

As long as the functions' arguments an return types are simple enough,
it seems doable. But have you something in mind for cases such as

AClass foo(SomeOtherClass other);

?

-- 
Óscar



From anton at korobeynikov.info  Tue Jun 16 13:17:03 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Wed, 17 Jun 2009 00:17:03 +0400
Subject: [LLVMdev] PIC documentation ?
In-Reply-To: <9719867c0906161240s428a8569ub0d0a453faa9d679@mail.gmail.com>
References: <8653927FD91A400AB077D2EF48F7132D@HPLAPTOP>
	<b087fca00906142127n55bcaa7bi729be3d6c2e9ae56@mail.gmail.com>
	<9719867c0906161240s428a8569ub0d0a453faa9d679@mail.gmail.com>
Message-ID: <b087fca00906161317n58054f43wb9a334d9f7eb6c14@mail.gmail.com>

Hello, Aaron

> Can I ask what platform ABI's are documented other than Itanium ?
I'd bet all platform ABI are more or less documented.

> I need to get to understand PIC on x86, x86_64 and PowerPC for the COFF and MachO backends.
ABI is normally induced by platform, not by architecture or object
file format (however they can influence on it).

1. Windows is PIC by design. Google for PE file format and for
'relocs' section. This corresponds to LLVM's DynamicNoPIC
2. ABI docs for Darwin (x86, x86_64, ppc, ppc64) you might find
somewhere @apple.com. There you can have all 3 types of PIC code:
static (no pic at all), DynamicNoPIC and full PIC.
3. COFF is usually not used on PPC at all (maybe on some old AIX'es?).

PS: Since you did not mention ELF, I assume you already found ABI docs
for it (for all platforms).
--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University


From clattner at apple.com  Tue Jun 16 13:24:30 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 16 Jun 2009 13:24:30 -0700
Subject: [LLVMdev] Tooling support for LLVM-GCC, or CLANG?
In-Reply-To: <80a70730906161305j1e12e73ep80d9d774907c22c3@mail.gmail.com>
References: <80a70730906160604v5c7c2bd1n5813924a9d5ff691@mail.gmail.com>
	<16e5fdf90906161147k246b36b4o5e0cfeba3efe0b18@mail.gmail.com>
	<80a70730906161305j1e12e73ep80d9d774907c22c3@mail.gmail.com>
Message-ID: <7299D30A-34FD-4FBF-93CA-8B912FBB8E3C@apple.com>

On Jun 16, 2009, at 1:05 PM, Granville Barnett wrote:
> I'm more interested in whether or not there are any projects in the  
> works that fuse the tools together to build a better IDE experience.  
> I forget which presentation it was, but one of the developers (I  
> *think* it was the gentleman that presented something on CLANG at  
> the dev's conference 2008) made a bit of a point by saying that  
> LLVM, unlike GCC has been built from the ground up with tooling in  
> mind. I appreciate that the tools that ship with LLVM use the  
> foundation in place, however, I am curious as to whether there are  
> any IDE projects that are building further upon this.

Hi Granville,

I'm not aware of anything publicly announced that is taking advantage  
of this yet.

-Chris

>
> Granville
>
> On Tue, Jun 16, 2009 at 7:47 PM, Bill Wendling <isanbard at gmail.com>  
> wrote:
> On Tue, Jun 16, 2009 at 6:04 AM, Granville
> Barnett<granvillebarnett at googlemail.com> wrote:
> > Hi,
> > I seem to remember that a big point of LLVM being built with  
> tooling support
> > out of the box was a major thing, however, I've not read anything  
> about any
> > tools which are actually taking advantage of the foundation LLVM  
> provides.
> > I'm not a Mac user, but I'd assume XCode would be a prime  
> candidate -
> > does/will XCode use LLVMs foundation to create a better IDE  
> experience?
> > Also, anyone know of similar efforts for Linux-based IDEs?
>
> Hi Granville,
>
> Clang itself takes advantage of the LLVM libraries
> (http://clang.llvm.org/). The static analyzer takes advantage of the
> clang libraries (same URL). There are a host of tools in the tools/
> sub-directory, which all use the LLVM libraries.
>
> :-)
>
> -bw
> _______________________________________________
> 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.llvm.org/pipermail/llvm-dev/attachments/20090616/00bb5f9b/attachment.html>

From dalej at apple.com  Tue Jun 16 13:29:32 2009
From: dalej at apple.com (Dale Johannesen)
Date: Tue, 16 Jun 2009 13:29:32 -0700
Subject: [LLVMdev] PIC documentation ?
In-Reply-To: <b087fca00906161317n58054f43wb9a334d9f7eb6c14@mail.gmail.com>
References: <8653927FD91A400AB077D2EF48F7132D@HPLAPTOP>
	<b087fca00906142127n55bcaa7bi729be3d6c2e9ae56@mail.gmail.com>
	<9719867c0906161240s428a8569ub0d0a453faa9d679@mail.gmail.com>
	<b087fca00906161317n58054f43wb9a334d9f7eb6c14@mail.gmail.com>
Message-ID: <F8B1DEC7-BA1E-4492-9E0A-DDD0DFCAAA86@apple.com>


On Jun 16, 2009, at 1:17 PMPDT, Anton Korobeynikov wrote:

> Hello, Aaron
>
>> Can I ask what platform ABI's are documented other than Itanium ?
> I'd bet all platform ABI are more or less documented.
>
>> I need to get to understand PIC on x86, x86_64 and PowerPC for the  
>> COFF and MachO backends.
> ABI is normally induced by platform, not by architecture or object
> file format (however they can influence on it).
>
> 1. Windows is PIC by design. Google for PE file format and for
> 'relocs' section. This corresponds to LLVM's DynamicNoPIC
> 2. ABI docs for Darwin (x86, x86_64, ppc, ppc64) you might find
> somewhere @apple.com. There you can have all 3 types of PIC code:
> static (no pic at all), DynamicNoPIC and full PIC.

The Apple ABI document is here, but doesn't really talk about PIC:
http://developer.apple.com/documentation/DeveloperTools/Conceptual/LowLevelABI/000-Introduction/introduction.html

> 3. COFF is usually not used on PPC at all (maybe on some old AIX'es?).
>
> PS: Since you did not mention ELF, I assume you already found ABI docs
> for it (for all platforms).
> --
> 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



From aaronngray.lists at googlemail.com  Tue Jun 16 13:40:31 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Tue, 16 Jun 2009 21:40:31 +0100
Subject: [LLVMdev] PIC documentation ?
References: <8653927FD91A400AB077D2EF48F7132D@HPLAPTOP><b087fca00906142127n55bcaa7bi729be3d6c2e9ae56@mail.gmail.com><9719867c0906161240s428a8569ub0d0a453faa9d679@mail.gmail.com>
	<b087fca00906161317n58054f43wb9a334d9f7eb6c14@mail.gmail.com>
Message-ID: <E791E720696742D2925CB5F9ECD5E587@HPLAPTOP>

Anton,

>> Can I ask what platform ABI's are documented other than Itanium ?
> I'd bet all platform ABI are more or less documented.

Right.

Maybe we should collect references and do some LLVM PIC documentation and 
put it on LLVM website ?

>> I need to get to understand PIC on x86, x86_64 and PowerPC for the COFF 
>> and MachO backends.
> ABI is normally induced by platform, not by architecture or object
> file format (however they can influence on it).

Yes.

> 1. Windows is PIC by design. Google for PE file format and for
> 'relocs' section. This corresponds to LLVM's DynamicNoPIC

Okay I have this documentation.

> 2. ABI docs for Darwin (x86, x86_64, ppc, ppc64) you might find
> somewhere @apple.com. There you can have all 3 types of PIC code:
> static (no pic at all), DynamicNoPIC and full PIC.

Okay. We need documentation, what is the difference between DynamicNoPIC and 
full PIC ?

> 3. COFF is usually not used on PPC at all (maybe on some old AIX'es?).

Yes.

> Since you did not mention ELF, I assume you already found ABI docs
> for it (for all platforms).

I am not working on the ELF backend, but could not understand the PIC code 
in the ELF documentation.

Thanks,

Aaron



From aaronngray.lists at googlemail.com  Tue Jun 16 13:41:36 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Tue, 16 Jun 2009 21:41:36 +0100
Subject: [LLVMdev] PIC documentation ?
References: <8653927FD91A400AB077D2EF48F7132D@HPLAPTOP><b087fca00906142127n55bcaa7bi729be3d6c2e9ae56@mail.gmail.com><9719867c0906161240s428a8569ub0d0a453faa9d679@mail.gmail.com><b087fca00906161317n58054f43wb9a334d9f7eb6c14@mail.gmail.com>
	<F8B1DEC7-BA1E-4492-9E0A-DDD0DFCAAA86@apple.com>
Message-ID: <25C12039258A4AFC8A37400002EE73AE@HPLAPTOP>

>> 2. ABI docs for Darwin (x86, x86_64, ppc, ppc64) you might find
>> somewhere @apple.com. There you can have all 3 types of PIC code:
>> static (no pic at all), DynamicNoPIC and full PIC.
>
> The Apple ABI document is here, but doesn't really talk about PIC:
> http://developer.apple.com/documentation/DeveloperTools/Conceptual/LowLevelABI/000-Introduction/introduction.html
>

Thanks Dale,

Aaron



From granvillebarnett at googlemail.com  Tue Jun 16 13:42:09 2009
From: granvillebarnett at googlemail.com (Granville Barnett)
Date: Tue, 16 Jun 2009 21:42:09 +0100
Subject: [LLVMdev] Tooling support for LLVM-GCC, or CLANG?
In-Reply-To: <7299D30A-34FD-4FBF-93CA-8B912FBB8E3C@apple.com>
References: <80a70730906160604v5c7c2bd1n5813924a9d5ff691@mail.gmail.com>
	<16e5fdf90906161147k246b36b4o5e0cfeba3efe0b18@mail.gmail.com>
	<80a70730906161305j1e12e73ep80d9d774907c22c3@mail.gmail.com>
	<7299D30A-34FD-4FBF-93CA-8B912FBB8E3C@apple.com>
Message-ID: <80a70730906161342qb53b6cdsef7a9302c450c04f@mail.gmail.com>

Hi Chris,
Thank you for clarifying.

Granville

On Tue, Jun 16, 2009 at 9:24 PM, Chris Lattner <clattner at apple.com> wrote:

> On Jun 16, 2009, at 1:05 PM, Granville Barnett wrote:
>
> I'm more interested in whether or not there are any projects in the works
> that fuse the tools together to build a better IDE experience. I forget
> which presentation it was, but one of the developers (I *think* it was the
> gentleman that presented something on CLANG at the dev's conference 2008)
> made a bit of a point by saying that LLVM, unlike GCC has been built from
> the ground up with tooling in mind. I appreciate that the tools that ship
> with LLVM use the foundation in place, however, I am curious as to whether
> there are any IDE projects that are building further upon this.
>
>
> Hi Granville,
>
> I'm not aware of anything publicly announced that is taking advantage of
> this yet.
>
> -Chris
>
>
> Granville
>
> On Tue, Jun 16, 2009 at 7:47 PM, Bill Wendling <isanbard at gmail.com> wrote:
>
>> On Tue, Jun 16, 2009 at 6:04 AM, Granville
>> Barnett<granvillebarnett at googlemail.com> wrote:
>> > Hi,
>> > I seem to remember that a big point of LLVM being built with tooling
>> support
>> > out of the box was a major thing, however, I've not read anything about
>> any
>> > tools which are actually taking advantage of the foundation LLVM
>> provides.
>> > I'm not a Mac user, but I'd assume XCode would be a prime candidate -
>> > does/will XCode use LLVMs foundation to create a better IDE experience?
>> > Also, anyone know of similar efforts for Linux-based IDEs?
>>
>> Hi Granville,
>>
>> Clang itself takes advantage of the LLVM libraries
>> (http://clang.llvm.org/). The static analyzer takes advantage of the
>> clang libraries (same URL). There are a host of tools in the tools/
>> sub-directory, which all use the LLVM libraries.
>>
>> :-)
>>
>> -bw
>> _______________________________________________
>> 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
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>


-- 
Granville Barnett
http://gbarnett.github.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090616/ce266481/attachment.html>

From victor at optirisk-systems.com  Tue Jun 16 14:00:12 2009
From: victor at optirisk-systems.com (Victor Zverovich)
Date: Tue, 16 Jun 2009 22:00:12 +0100
Subject: [LLVMdev] runtime library for jitted code
In-Reply-To: <87ocsoc583.fsf@telefonica.net>
References: <a88d534c0906150235w6f0e3ce3i4302f4eeae6b03d0@mail.gmail.com>
	<4A365D35.3040005@t-online.de> <87ski1cxbl.fsf@telefonica.net>
	<a88d534c0906160957n58ae9efdqcaeb5fb3ee38da5@mail.gmail.com>
	<87ocsoc583.fsf@telefonica.net>
Message-ID: <a88d534c0906161400u90ae6d0oac8f7bae5a7fad05@mail.gmail.com>

Unfortunately I have no idea how to to properly declare such prototype in
LLVM so that it was compatible with the code generated by Visual C++. So I
am considering only simple cases (numeric types and pointers).

Victor

2009/6/16 Óscar Fuentes <ofv at wanadoo.es>

> Victor Zverovich <victor.zverovich at googlemail.com> writes:
>
> > The question about the name mangling gave me an idea that it can be used
> to
> > automate registration of DLL functions. Instead of manually creating
> > Function objects specifying a return type and argument types which is
> > error-prone and time-consuming one can get a list of functions exported
> from
> > a DLL using Windows API, demangle each name and construct a Function
> object
> > from it. Is there any support for Visual C++ style (de)mangling in LLVM
> or
> > related project? In any case I think it won't be difficult for me to
> write
> > such a converter from mangled names to LLVM function declarations.
>
> As long as the functions' arguments an return types are simple enough,
> it seems doable. But have you something in mind for cases such as
>
> AClass foo(SomeOtherClass other);
>
> ?
>
> --
> Óscar
>
> _______________________________________________
> 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.llvm.org/pipermail/llvm-dev/attachments/20090616/84f75d87/attachment.html>

From anton at korobeynikov.info  Tue Jun 16 14:16:17 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Wed, 17 Jun 2009 01:16:17 +0400
Subject: [LLVMdev] PIC documentation ?
In-Reply-To: <E791E720696742D2925CB5F9ECD5E587@HPLAPTOP>
References: <8653927FD91A400AB077D2EF48F7132D@HPLAPTOP>
	<b087fca00906142127n55bcaa7bi729be3d6c2e9ae56@mail.gmail.com>
	<9719867c0906161240s428a8569ub0d0a453faa9d679@mail.gmail.com>
	<b087fca00906161317n58054f43wb9a334d9f7eb6c14@mail.gmail.com>
	<E791E720696742D2925CB5F9ECD5E587@HPLAPTOP>
Message-ID: <b087fca00906161416i726620f8o5d1f74cfe26ea3ab@mail.gmail.com>

Aaron,

> Maybe we should collect references and do some LLVM PIC documentation and
> put it on LLVM website ?
What you mean as "LLVM PIC documentation"? What should be included there?

> Okay. We need documentation, what is the difference between DynamicNoPIC and
> full PIC ?
>From TargetMachine.cpp (actually this is show in llc --help):

  cl::values(
    clEnumValN(Reloc::Default, "default",
               "Target default relocation model"),
    clEnumValN(Reloc::Static, "static",
               "Non-relocatable code"),
    clEnumValN(Reloc::PIC_, "pic",
               "Fully relocatable, position independent code"),
    clEnumValN(Reloc::DynamicNoPIC, "dynamic-no-pic",
               "Relocatable external references, non-relocatable code"),
    clEnumValEnd));

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


From aaronngray.lists at googlemail.com  Tue Jun 16 14:49:26 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Tue, 16 Jun 2009 22:49:26 +0100
Subject: [LLVMdev] PIC documentation ?
References: <8653927FD91A400AB077D2EF48F7132D@HPLAPTOP><b087fca00906142127n55bcaa7bi729be3d6c2e9ae56@mail.gmail.com><9719867c0906161240s428a8569ub0d0a453faa9d679@mail.gmail.com><b087fca00906161317n58054f43wb9a334d9f7eb6c14@mail.gmail.com><E791E720696742D2925CB5F9ECD5E587@HPLAPTOP>
	<b087fca00906161416i726620f8o5d1f74cfe26ea3ab@mail.gmail.com>
Message-ID: <36251B6D469B4BDD8DC957A93D9AB74B@HPLAPTOP>

>> Maybe we should collect references and do some LLVM PIC documentation and
>> put it on LLVM website ?
> What you mean as "LLVM PIC documentation"? What should be included there?

Good question, if I had a proper overview of LLVM PIC implmentation then I 
would know :)

>> Okay. We need documentation, what is the difference between DynamicNoPIC 
>> and
>> full PIC ?
>>From TargetMachine.cpp (actually this is show in llc --help):
>
>  cl::values(
>    clEnumValN(Reloc::Default, "default",
>               "Target default relocation model"),
>    clEnumValN(Reloc::Static, "static",
>               "Non-relocatable code"),
>    clEnumValN(Reloc::PIC_, "pic",
>               "Fully relocatable, position independent code"),
>    clEnumValN(Reloc::DynamicNoPIC, "dynamic-no-pic",
>               "Relocatable external references, non-relocatable code"),
>    clEnumValEnd));

This tells me a bit but very little.

Okay I will have to study the code, I was hoping not to have to do that.

Aaron



From dag at cray.com  Tue Jun 16 14:52:39 2009
From: dag at cray.com (David Greene)
Date: Tue, 16 Jun 2009 16:52:39 -0500
Subject: [LLVMdev] Loop alignment
Message-ID: <200906161652.39447.dag@cray.com>

For the X86 target, where is the code that spits out
alignment directives and/or code for loops as determined by the
LoopAligner pass?

                        -Dave


From dalej at apple.com  Tue Jun 16 14:53:08 2009
From: dalej at apple.com (Dale Johannesen)
Date: Tue, 16 Jun 2009 14:53:08 -0700
Subject: [LLVMdev] PIC documentation ?
In-Reply-To: <E791E720696742D2925CB5F9ECD5E587@HPLAPTOP>
References: <8653927FD91A400AB077D2EF48F7132D@HPLAPTOP>
	<b087fca00906142127n55bcaa7bi729be3d6c2e9ae56@mail.gmail.com>
	<9719867c0906161240s428a8569ub0d0a453faa9d679@mail.gmail.com>
	<b087fca00906161317n58054f43wb9a334d9f7eb6c14@mail.gmail.com>
	<E791E720696742D2925CB5F9ECD5E587@HPLAPTOP>
Message-ID: <2921D123-B555-41EA-AACB-DA758E55C153@apple.com>

>> 2. ABI docs for Darwin (x86, x86_64, ppc, ppc64) you might find
>> somewhere @apple.com. There you can have all 3 types of PIC code:
>> static (no pic at all), DynamicNoPIC and full PIC.
>
> Okay. We need documentation, what is the difference between  
> DynamicNoPIC and
> full PIC ?

The best way to figure this out is to run  a small program through and  
look at the output I think.  It's not considered part of the ABI, as  
it doesn't affect the callee or the codegen for variable  
definitions....note that the code sequences for function calls also  
varied in compilers earlier than gcc-4.2, and OS's earlier than  
Leopard.  Look for getDarwinVers in the X86 and PPC back ends and look  
around for "stubs" if you want to support Tiger.

int x;
void foo() {
   return x;
}

Results on x86-32 with -fomit-frame-pointer (which is not the default):
result of -fPIC (equivalent to -fpic on Darwin):
_foo:
         call    L3
"L00000000001$pb":
         popl    %ecx                   << gets value of PC into %ecx  
(other registers can be used)
         movl    L_x$non_lazy_ptr-"L00000000001$pb"(%ecx), %eax     <<  
gets &x; PC relative
         movl    (%eax), %eax       << gets x; indirect
         ret
.comm _x,4,2
         .section __IMPORT,__pointers,non_lazy_symbol_pointers
L_x$non_lazy_ptr:
         .indirect_symbol _x   << magic cookie for indirect  
references, must be in this magic section
         .long   0

Result of -mdynamic-no-pic:
_foo:
         movl    L_x$non_lazy_ptr, %eax       << &x, not PC relative
         movl    (%eax), %eax              << gets x; indirect
         ret
.comm _x,4,2
         .section __IMPORT,__pointers,non_lazy_symbol_pointers
L_x$non_lazy_ptr:
         .indirect_symbol _x
         .long   0

Result of -static:
_foo:
         movl    _x, %eax      << direct reference
         ret
.comm _x,4,2



From dag at cray.com  Tue Jun 16 15:00:06 2009
From: dag at cray.com (David Greene)
Date: Tue, 16 Jun 2009 17:00:06 -0500
Subject: [LLVMdev] Some understanding of LLVM vs gCC vs Intel C++
	Compilers
In-Reply-To: <200906160651.42044.jon@ffconsultancy.com>
References: <FAD2E372-2FC6-410E-9ECE-1AEAD896996D@MailNewsRSS.com>
	<200906151843.58729.dag@cray.com>
	<200906160651.42044.jon@ffconsultancy.com>
Message-ID: <200906161700.07438.dag@cray.com>

On Tuesday 16 June 2009 00:51, Jon Harrop wrote:

> I just noticed your post and was wondering what Cray are doing with LLVM?
> Are you using it in production?
>
> I am trying to keep an eye on the fast moving LLVM project and like to keep
> up to date with respect to its industrial applications...

We're on the LLVM users page, but that probably needs an update.  I'll look at 
checking something in.

The Cray X86 compiler is in use by customers today.  The first release 
happened in December with an update coming RSN.  It's being used for real
science, today, on massively parallel supercomputers.  We're talking tens of
thousands of processors.

So all you LLVM developers, put another feather in your cap.  Our (yours and 
Cray compiler devlopers') code is being used to solve the world's most
challenging and groundbreaking scientific problems!

                               -Dave


From dag at cray.com  Tue Jun 16 15:05:48 2009
From: dag at cray.com (David Greene)
Date: Tue, 16 Jun 2009 17:05:48 -0500
Subject: [LLVMdev]
	=?iso-8859-1?q?Some_understanding_of_LLVM_vs_gCC_vs_Int?=
	=?iso-8859-1?q?el_C++=09Compilers?=
In-Reply-To: <2216C982-A68A-4B14-B6A0-27B47D694733@apple.com>
References: <FAD2E372-2FC6-410E-9ECE-1AEAD896996D@MailNewsRSS.com>
	<80a70730906160559p369550f7qc24951ecfae67c0f@mail.gmail.com>
	<2216C982-A68A-4B14-B6A0-27B47D694733@apple.com>
Message-ID: <200906161705.49214.dag@cray.com>

On Tuesday 16 June 2009 09:49, Dan Gohman wrote:
> Trying to capture a notion of overall compiler optimization
> in a representative set of benchmarks is a hard problem.
> If you're interested in performance, it's best to measure it
> on the applications you're interested in.
>
> You should be suspicious of any one-dimensional analysis
> of compiler optimization, especially if it's presented by
> someone with an interest in a particular compiler.

That's exactly right.

I have seen codes where even minor tweaks to a register allocation spilling 
heuristic can have a 10-20% performance impact on X86.  Compiler 
transformations are often very sensitive to particular pieaces of code.

It's impossible to declare one compiler "better" than another because it's 
likely the design goals of the compilers are quite different.

The great advantage of LLVM/Clang, in my mind, is its clean design and
relatively shallow learning curve.  It's not only a smart business decision
to use the code because of its utilitarian value, it's smart from an
employee training perspective as well.

All IMHO, nothing I say here is an official Cray position, blah, blah, 
blah.  :)

                             -Dave


From dag at cray.com  Tue Jun 16 15:12:54 2009
From: dag at cray.com (David Greene)
Date: Tue, 16 Jun 2009 17:12:54 -0500
Subject: [LLVMdev] x86 Intel Syntax and MASM 9.x
In-Reply-To: <512D8C46F5CB4E69AA3F8D99595A7CE2@HPLAPTOP>
References: <D79A8D1CEFA38E45AD075F6EB49D9E8C0D53EFC6@sefsexmb1.amd.com>
	<f5aa3e9b0906151843g22b608a7u8397ee4854f17392@mail.gmail.com>
	<512D8C46F5CB4E69AA3F8D99595A7CE2@HPLAPTOP>
Message-ID: <200906161712.54426.dag@cray.com>

On Tuesday 16 June 2009 09:48, Aaron Gray wrote:

> Appently the GAS Intel backend has flaws and does not work correctly anyway
> so the X86IntelAsm backend is designed only to target MASM anyway.

gas Intel syntax is indeed broken in LLVM.  I'd love to make it work but
my work has not (yet) allocated time for that.  Maybe I can hack LLVM on
the weekends.  :)

The above discussion leads me to believe there are fundamental conflicts 
between MASM and gas syntax.

Is NASM any better than MASM?

I would hate for MASM to impose draconian restrictions on the Intel asm
printer for all targets.

Do we need a third asm printer?

                             -Dave


From clattner at apple.com  Tue Jun 16 15:28:54 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 16 Jun 2009 15:28:54 -0700
Subject: [LLVMdev] x86 Intel Syntax and MASM 9.x
In-Reply-To: <200906161712.54426.dag@cray.com>
References: <D79A8D1CEFA38E45AD075F6EB49D9E8C0D53EFC6@sefsexmb1.amd.com>
	<f5aa3e9b0906151843g22b608a7u8397ee4854f17392@mail.gmail.com>
	<512D8C46F5CB4E69AA3F8D99595A7CE2@HPLAPTOP>
	<200906161712.54426.dag@cray.com>
Message-ID: <96227E42-A45C-4A5E-B8D0-EA265B2DD4F7@apple.com>


On Jun 16, 2009, at 3:12 PM, David Greene wrote:

> On Tuesday 16 June 2009 09:48, Aaron Gray wrote:
>
>> Appently the GAS Intel backend has flaws and does not work  
>> correctly anyway
>> so the X86IntelAsm backend is designed only to target MASM anyway.
>
> gas Intel syntax is indeed broken in LLVM.  I'd love to make it work  
> but
> my work has not (yet) allocated time for that.  Maybe I can hack  
> LLVM on
> the weekends.  :)
>
> The above discussion leads me to believe there are fundamental  
> conflicts
> between MASM and gas syntax.
>
> Is NASM any better than MASM?
>
> I would hate for MASM to impose draconian restrictions on the Intel  
> asm
> printer for all targets.

Personally, I'd rather just bring up a PE COFF writer and use the masm  
backend for "debugging".

-Chris


From aaronngray.lists at googlemail.com  Tue Jun 16 15:34:01 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Tue, 16 Jun 2009 23:34:01 +0100
Subject: [LLVMdev] PIC documentation ?
References: <8653927FD91A400AB077D2EF48F7132D@HPLAPTOP><b087fca00906142127n55bcaa7bi729be3d6c2e9ae56@mail.gmail.com><9719867c0906161240s428a8569ub0d0a453faa9d679@mail.gmail.com><b087fca00906161317n58054f43wb9a334d9f7eb6c14@mail.gmail.com><E791E720696742D2925CB5F9ECD5E587@HPLAPTOP>
	<2921D123-B555-41EA-AACB-DA758E55C153@apple.com>
Message-ID: <FB0EDF8F32BE4B78963DD0B17AB160B9@HPLAPTOP>

>>> 2. ABI docs for Darwin (x86, x86_64, ppc, ppc64) you might find
>>> somewhere @apple.com. There you can have all 3 types of PIC code:
>>> static (no pic at all), DynamicNoPIC and full PIC.
>>
>> Okay. We need documentation, what is the difference between  
>> DynamicNoPIC and
>> full PIC ?
> 
> The best way to figure this out is to run  a small program through and  
> look at the output I think.  It's not considered part of the ABI, as  
> it doesn't affect the callee or the codegen for variable  
> definitions....note that the code sequences for function calls also  
> varied in compilers earlier than gcc-4.2, and OS's earlier than  
> Leopard.  Look for getDarwinVers in the X86 and PPC back ends and look  
> around for "stubs" if you want to support Tiger.

Great thats the way to do it, very obvious solution !

Thanks for the hints Dale,

Aaron



From aaronngray.lists at googlemail.com  Tue Jun 16 15:41:01 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Tue, 16 Jun 2009 23:41:01 +0100
Subject: [LLVMdev] x86 Intel Syntax and MASM 9.x
References: <D79A8D1CEFA38E45AD075F6EB49D9E8C0D53EFC6@sefsexmb1.amd.com><f5aa3e9b0906151843g22b608a7u8397ee4854f17392@mail.gmail.com><512D8C46F5CB4E69AA3F8D99595A7CE2@HPLAPTOP>
	<200906161712.54426.dag@cray.com>
Message-ID: <8B2AAF36FF31421893D78ABC1D154993@HPLAPTOP>

> On Tuesday 16 June 2009 09:48, Aaron Gray wrote:
>
>> Appently the GAS Intel backend has flaws and does not work correctly 
>> anyway
>> so the X86IntelAsm backend is designed only to target MASM anyway.
>
> gas Intel syntax is indeed broken in LLVM.  I'd love to make it work but
> my work has not (yet) allocated time for that.  Maybe I can hack LLVM on
> the weekends.  :)

I think writing an assembler using LLVM Table gen and data, and using the 
DOCE (Direct Object Code Emission) backends (see LLVM Wiki for details) when 
they are ready is a much better solution. I am planning on doing a full tool 
set (linker, and librarian anyway) to replace binutils for LLVM on Windows, 
and maybe for other bianry formats. Although this will take time, hopefully 
we will get more people working on it when there is something basic running 
as a proof of concept.

> The above discussion leads me to believe there are fundamental conflicts
> between MASM and gas syntax.
>
> Is NASM any better than MASM?

Probably if MASM does not support aligns or weak symbols properly.

> I would hate for MASM to impose draconian restrictions on the Intel asm
> printer for all targets.

Yes.

> Do we need a third asm printer?

I think so.

Aaron



From aaronngray.lists at googlemail.com  Tue Jun 16 15:44:51 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Tue, 16 Jun 2009 23:44:51 +0100
Subject: [LLVMdev] x86 Intel Syntax and MASM 9.x
References: <D79A8D1CEFA38E45AD075F6EB49D9E8C0D53EFC6@sefsexmb1.amd.com><f5aa3e9b0906151843g22b608a7u8397ee4854f17392@mail.gmail.com><512D8C46F5CB4E69AA3F8D99595A7CE2@HPLAPTOP><200906161712.54426.dag@cray.com>
	<96227E42-A45C-4A5E-B8D0-EA265B2DD4F7@apple.com>
Message-ID: <DC00947543DA4E279E83A281FEC40822@HPLAPTOP>

> On Jun 16, 2009, at 3:12 PM, David Greene wrote:
>
>> On Tuesday 16 June 2009 09:48, Aaron Gray wrote:
>>
>>> Appently the GAS Intel backend has flaws and does not work
>>> correctly anyway
>>> so the X86IntelAsm backend is designed only to target MASM anyway.
>>
>> gas Intel syntax is indeed broken in LLVM.  I'd love to make it work
>> but
>> my work has not (yet) allocated time for that.  Maybe I can hack
>> LLVM on
>> the weekends.  :)
>>
>> The above discussion leads me to believe there are fundamental
>> conflicts
>> between MASM and gas syntax.
>>
>> Is NASM any better than MASM?
>>
>> I would hate for MASM to impose draconian restrictions on the Intel
>> asm
>> printer for all targets.
>
> Personally, I'd rather just bring up a PE COFF writer and use the masm
> backend for "debugging".

You really need COFF object modules and a linker as you generally need other 
libraries linked in too.

Direct PE or COFF plus binutils linker could be stopgaps too.

Aaron



From azaks at sta.samsung.com  Tue Jun 16 16:09:14 2009
From: azaks at sta.samsung.com (Anna Zaks)
Date: Tue, 16 Jun 2009 18:09:14 -0500
Subject: [LLVMdev] Using LLVM on an embedded device
Message-ID: <ADCE5AA1DF84024C88B9B8A29D9553C6041977CD@mx2.telecom.sna.samsung.com>

Hi,

 

I am researching a possibility of running LLVM components (such as JIT)
on an embedded device, where the memory footprint and RAM usage are the
main concerns. So I was wondering if anyone could share their experience
with running LLVM on an embedded device. What is the approximate code
footprint that we are looking at? For example, on an x86 with a minimum
set of optimizations and with only the x86 backend, it seems difficult
to get the LLVM JIT occupy less than 5MB. Is there any performance and
memory usage data available?

 

Thank you!

Anna.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090616/d9bae811/attachment.html>

From dag at cray.com  Tue Jun 16 17:35:51 2009
From: dag at cray.com (David Greene)
Date: Tue, 16 Jun 2009 19:35:51 -0500
Subject: [LLVMdev] Regular Expressions
In-Reply-To: <09C9C325-2B00-4C3F-8A11-93FC60B2BDB4@apple.com>
References: <200906081700.n58H0Zvi022899@zion.cs.uiuc.edu>
	<4A369415.50207@cray.com>
	<09C9C325-2B00-4C3F-8A11-93FC60B2BDB4@apple.com>
Message-ID: <200906161935.52304.dag@cray.com>

On Monday 15 June 2009 14:35, Chris Lattner wrote:

> > I suppose you could argue that additional parameters specifying
> > the source and dest types could be passed, but why bother when
> > it is already encoded in the mnemonic?  That would just be
> > adding error-prone redundancy.
>
> Why not synthesize the opcode string from the information passed down?

That's actually how I started things out initially.  The problem is that it 
leads to a less intuitive specification.  I'll see if I can illustrate.

Say we have a wrapper class like this:

class X86ValueType {
    ValueType VT;
    RegisterClass RegClass;
    string suffix;
}

Now we instantiate some concrete types:

class X86_f32 : X86ValueType {
  let VT = f32;
  let RegClass = FR32;
  let suffix = "ss";
}

class X86_v4f32 : X86ValueType {
  let VT = v4f32;
  let RegClass = VR128;
  let suffix = "ps";
}

class X86_v8f32 : X86ValueType {
  let VT = v8f32;
  let RegClass = VR256;
  let suffix = "ps";
}

Ok, you get the picture.  Now let's look at how we would write instruction 
patterns:

defm BLENDPS  : sse41_avx_fp_binary_vector_osta_vintrinsic_rmi_rrmi<0x0C, 
                  i32i8imm, "blend", "blend", "f32">;
defm BLENDPD  : sse41_avx_fp_binary_vector_osta_vintrinsic_rmi_rrmi<0x0D, 
                  i32i8imm, "blend", "blend", "f64">;

We have to send types as strings because we need to be able to munge them
for SSE vs. AVX.  Passing multiple types (v4f32, v8f32, etc.) is not
practical, it just obfuscates the top-level specification.

Now we need some guts:

multiclass sse41_avx_fp_binary_vector_osta_vintrinsic_rmi_rrmi<
  bits<8> opc,
  PatFrag ImmClass,
  string OpcodeString,
  string Intrinsic,
  string BaseType,
  list<list<dag>> ipatterns = [],
  string asm = ""
> {
  def rr_Int : ... 
  def rm_Int : ...
  def V#NAME#_128rrr_Int : fp_binary_vector_irrr<
    opc,
    // I'm not even sure this field reference will work
    !strconcat(OpcodeStr, 
               !cast<X86ValueType>(!strconcat("X86v??", 
                                              BaseType)).suffix,
    !strconcat(Intrinsic, 
               !strconcat("_", 
                          !cast<X86ValueType>(!strconcat("X86v??", 
                                                         BaseType)).suffix,
    cast<X86ValueType>(!strconcat("X86v??", BaseType)).VT,
    cast<X86ValueType>(!strconcat("X86v??", BaseType)).RegClass, // Src
    cast<X86ValueType>(!strconcat("X86v??", BaseType)).RegClass, // Dst
    [and probably some other stuff],
    ipatterns,
    asm
  > {
    let Prefix = TA;
    let HasOpSize = 1;
    let HasVEX = 1;
  }
  def V#NAME#_128rrm_Int : ...
  def V#NAME#_256rrr_Int : ... {
    let Prefix = TA;
    let HasOpSize = 1;
    let HasVEX = 1;
    let HasVEX_L = 1;
  }
  def V#NAME#_256rrm_Int : ...
}

Ok, that's the first level and right here we have a problem.  How do we figure 
out the vector length ("??" in the strings)?  We could pass it at the top 
level:

defm BLENDPS  : sse41_avx_fp_binary_vector_osta_vintrinsic_rmi_rrmi<0x0C, 
                  i32i8imm, "blend", "blend", "f32", 4>;

Now 4 is not the right vector length for VEX.L-encoded AVX, so we'll have to 
munge it:

multiclass sse41_avx_fp_binary_vector_osta_vintrinsic_rmi_rrmi<
  bits<8> opc,
  PatFrag ImmClass,
  string OpcodeString,
  string Intrinsic,
  string BaseType,
  int BaseVL,
  list<list<dag>> ipatterns = [],
  string asm = ""
> {
  [...]
  def V#NAME#_256rrr_Int : fp_binary_vector_irrr<
    opc,
    // Not even sure this field reference will work
    !strconcat(OpcodeStr, 
               !cast<X86ValueType>(!strconcat(
                   // No support for cast to string yet, but not hard to add
                   // Need integer multiply support as well
                                   !strconcat("X86v", cast<string>(2*BaseVL)), 
                                              BaseType)).suffix,
    [...]
  > {
    let Prefix = TA;
    let HasOpSize = 1;
    let HasVEX = 1;
    let HasVEX_L = 1;
  }
  [...]
}

All right, we can make it work, but is it really worth the pain?  I'm really 
concerned about making the top-level instruction specification .td as readable 
as possible, since that's what people will be primarily editing.

So which is more intuitive and less error-prone?  

defm BLENDPS  : sse41_avx_fp_binary_vector_osta_vintrinsic_rmi_rrmi<0x0C, 
                  i32i8imm, "blend", "blend", "f32", 4>;

or

defm BLENDPS  : sse41_avx_fp_binary_vector_osta_vintrinsic_rmi_rrmi<0x0C, 
                  i32i8imm, "blendps", "blendps">;

(We can probably drop the Intrinsic string specification since in most cases
we can generate it from the opcode string).

Before answering, consider that the developer must understand how top-level 
parameters like type strings and vector lengths will be munged by the guts 
classes.  She needs to know this to know what values to pass for types and 
vector lengths.

The key problem is the differing type requirements for AVX vs. SSE.  There is
always some munging of some parameter required at some point.  Those 
parameters have to be strings since that's the only type in TableGen
flexible enough to have munging performed on it.  We could add lots of 
operators to munge other types but that would be needlessly complex and
expensive to implement.

Opcode strings are naturally strings.  They contain all of the typing 
information we need.  I think it is better to pass fewer arguments and
let TableGen do the hard work of figuring out the type requirements.

If you buy that argument, we have to have some way to match string patterns.
Regular expressions is a natural solution.

                               -Dave


From dag at cray.com  Tue Jun 16 17:49:46 2009
From: dag at cray.com (David Greene)
Date: Tue, 16 Jun 2009 19:49:46 -0500
Subject: [LLVMdev] Regular Expressions
In-Reply-To: <200906161935.52304.dag@cray.com>
References: <200906081700.n58H0Zvi022899@zion.cs.uiuc.edu>
	<09C9C325-2B00-4C3F-8A11-93FC60B2BDB4@apple.com>
	<200906161935.52304.dag@cray.com>
Message-ID: <200906161949.47079.dag@cray.com>

On Tuesday 16 June 2009 19:35, David Greene wrote:

> So which is more intuitive and less error-prone?
>
> defm BLENDPS  : sse41_avx_fp_binary_vector_osta_vintrinsic_rmi_rrmi<0x0C,
>                   i32i8imm, "blend", "blend", "f32", 4>;
>
> or
>
> defm BLENDPS  : sse41_avx_fp_binary_vector_osta_vintrinsic_rmi_rrmi<0x0C,
>                   i32i8imm, "blendps", "blendps">;

Here's another option:

defm BLENDPS  : sse41_avx_fp_binary_vector_osta_vintrinsic_rmi_rrmi<0x0C,
                   i32i8imm, "blendps", "blendps", v4f32, v8f32>;

This is somewhere between the first and second options.  It's not as 
convenient as the second but is more intuitive than the first.  Still,
looking at some random individual instruction, it wouldn't be immediately
clear to me what those multiple types mean.  I might think they're source
and destination types, for example.

                                     -Dave


From aaronngray.lists at googlemail.com  Tue Jun 16 18:17:10 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Wed, 17 Jun 2009 02:17:10 +0100
Subject: [LLVMdev] Regular Expressions
References: <200906081700.n58H0Zvi022899@zion.cs.uiuc.edu><09C9C325-2B00-4C3F-8A11-93FC60B2BDB4@apple.com><200906161935.52304.dag@cray.com>
	<200906161949.47079.dag@cray.com>
Message-ID: <9997029E4A234CF8B537BB4042C06277@HPLAPTOP>

> On Tuesday 16 June 2009 19:35, David Greene wrote:
>
>> So which is more intuitive and less error-prone?
>>
>> defm BLENDPS  : sse41_avx_fp_binary_vector_osta_vintrinsic_rmi_rrmi<0x0C,
>>                   i32i8imm, "blend", "blend", "f32", 4>;
>>
>> or
>>
>> defm BLENDPS  : sse41_avx_fp_binary_vector_osta_vintrinsic_rmi_rrmi<0x0C,
>>                   i32i8imm, "blendps", "blendps">;
>
> Here's another option:
>
> defm BLENDPS  : sse41_avx_fp_binary_vector_osta_vintrinsic_rmi_rrmi<0x0C,
>                   i32i8imm, "blendps", "blendps", v4f32, v8f32>;
>
> This is somewhere between the first and second options.  It's not as
> convenient as the second but is more intuitive than the first.  Still,
> looking at some random individual instruction, it wouldn't be immediately
> clear to me what those multiple types mean.  I might think they're source
> and destination types, for example.

Named parameters might be a possible solution. Again maybe it might be too 
verbose.

Aaron



From anton at korobeynikov.info  Tue Jun 16 18:39:56 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Wed, 17 Jun 2009 05:39:56 +0400
Subject: [LLVMdev] x86 Intel Syntax and MASM 9.x
In-Reply-To: <8B2AAF36FF31421893D78ABC1D154993@HPLAPTOP>
References: <D79A8D1CEFA38E45AD075F6EB49D9E8C0D53EFC6@sefsexmb1.amd.com>
	<f5aa3e9b0906151843g22b608a7u8397ee4854f17392@mail.gmail.com>
	<512D8C46F5CB4E69AA3F8D99595A7CE2@HPLAPTOP>
	<200906161712.54426.dag@cray.com>
	<8B2AAF36FF31421893D78ABC1D154993@HPLAPTOP>
Message-ID: <b087fca00906161839i4c84c2cenef21efb6fa46aba9@mail.gmail.com>

> > The above discussion leads me to believe there are fundamental conflicts
> > between MASM and gas syntax.
> >
> > Is NASM any better than MASM?
>
> Probably if MASM does not support aligns or weak symbols properly.
FWIW: masm does not support much more :)

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


From sanjiv.gupta at microchip.com  Tue Jun 16 21:12:41 2009
From: sanjiv.gupta at microchip.com (Sanjiv Gupta)
Date: Wed, 17 Jun 2009 09:42:41 +0530
Subject: [LLVMdev] Localizing Globals ?
In-Reply-To: <f5aa3e9b0906160310y223ae6d7ve0842397b7f2594c@mail.gmail.com>
References: <4A376756.9010302@microchip.com>
	<f5aa3e9b0906160310y223ae6d7ve0842397b7f2594c@mail.gmail.com>
Message-ID: <4A386D39.2020404@microchip.com>

Eli Friedman wrote:
> On Tue, Jun 16, 2009 at 2:35 AM, Sanjiv Gupta<sanjiv.gupta at microchip.com> wrote:
>   
>> What if my global variable was into a different address space than stack?
>>     
>
> It doesn't matter in terms of semantics: because AnalyzeGlobal
> returned false, we're guaranteed the address of the global is never
> taken.  I wouldn't be surprised if we end up generating invalid IR in
> some cases, though, because of the semantics of replaceAllUsesWith.
> Do you have a testcase that breaks?
>
>   
The problem is replaceAllUsesWith asserts for type mismatch here. Try 
attached .bc with llvm-ld.

assert(New->getType() == getType() &&
         "replaceAllUses of value with new value of different type!");

Since stack is always on address space zero, I don't think that type of 
GV in a different address space is ever going to match.
The other way is to allow replaceAllUsesWith to ignore address spaces 
while comparing types. (do we have  a way to do that ?).
But then such an optimization may fail the entire idea of user wanting 
to place a variable into different memory space. The original idea of 
user might be to save on the stack space (data memory) and hence he 
asked the variable to be placed into different memory space (program 
memory). So the best bet here is to deny this optimization by checking

GV->getType()->getAddressSpace() == 0.

- Sanjiv


-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.bc
Type: application/octet-stream
Size: 1496 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090617/5068f2aa/attachment.obj>

From eli.friedman at gmail.com  Tue Jun 16 21:25:18 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Tue, 16 Jun 2009 21:25:18 -0700
Subject: [LLVMdev] Localizing Globals ?
In-Reply-To: <4A386D39.2020404@microchip.com>
References: <4A376756.9010302@microchip.com>
	<f5aa3e9b0906160310y223ae6d7ve0842397b7f2594c@mail.gmail.com>
	<4A386D39.2020404@microchip.com>
Message-ID: <f5aa3e9b0906162125p77bd83dfpfa5ee7468b359922@mail.gmail.com>

On Tue, Jun 16, 2009 at 9:12 PM, Sanjiv Gupta<sanjiv.gupta at microchip.com> wrote:
> The problem is replaceAllUsesWith asserts for type mismatch here. Try
> attached .bc with llvm-ld.
>
> assert(New->getType() == getType() &&
>        "replaceAllUses of value with new value of different type!");

Ah, right; it probably isn't worth the effort to fix this
transformation to work with alternate address spaces.

> But then such an optimization may fail the entire idea of user wanting to
> place a variable into different memory space. The original idea of user
> might be to save on the stack space (data memory) and hence he asked the
> variable to be placed into different memory space (program memory). So the
> best bet here is to deny this optimization by checking
>
> GV->getType()->getAddressSpace() == 0.

Yeah, that sounds good; mind putting together a patch?

-Eli



From nicholas at mxc.ca  Tue Jun 16 22:02:26 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Tue, 16 Jun 2009 22:02:26 -0700
Subject: [LLVMdev] help with tablegen
Message-ID: <4A3878E2.2010403@mxc.ca>

In order to make metadata useful to the backend, I'd like to permit 
intrinsics to be written that take metadata-typed objects. To allow 
this, I decided to try adding a new machine value type right next to isVoid.

I updated both ValueTypes.td and ValueTypes.h as well as 
TableGen/IntrinsicEmitter.cpp and TableGen/CodeGenTarget.cpp where they 
have switch(mvt). The actual patch is attached.

This runs into trouble with the X86 backend where the SSE2 forms of ADD 
are defined:

llvm[3]: Building X86.td DAG instruction selector implementation with tblgen
ADDPDrm:        (set:isVoid VR128:isFP:$dst, (fadd:isFP 
VR128:isFP:$src1, (ld:isFP 
addr:iPTR:$src2)<<P:Predicate_unindexedload>><<P:Predicate_load>><<P:Predicate_memop>>))
/home/nicholas/llvm-commit/Debug/bin/tblgen: error:
Included from X86.td:128:
Included from X86InstrInfo.td:3964:
Parsing X86InstrSSE.td:1320: In ADDPDrm: Could not infer all types in 
pattern!
defm ADD : basic_sse2_fp_binop_rm<0x58, "add", fadd, 
int_x86_sse2_add_sd, 1>;
      ^

I'm hoping someone with backend experience understands why this would 
happen. I've looked over the definition of basic_sse2_fp_binop_rm and 
can't see any way in which adding MVT::isMetadata should impact it or 
the type inference step.

I'm stumped. Does anyone have any suggestions?

Nick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mvt-metadata.patch
Type: text/x-patch
Size: 7893 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090616/e5cccc31/attachment.bin>

From evan.cheng at apple.com  Tue Jun 16 22:11:36 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Tue, 16 Jun 2009 22:11:36 -0700
Subject: [LLVMdev] Loop alignment
In-Reply-To: <200906161652.39447.dag@cray.com>
References: <200906161652.39447.dag@cray.com>
Message-ID: <801B1023-8F24-4121-99D1-69915EC5B344@apple.com>

Asm printer.

Evan

On Jun 16, 2009, at 2:52 PM, David Greene wrote:

> For the X86 target, where is the code that spits out
> alignment directives and/or code for loops as determined by the
> LoopAligner pass?
>
>                        -Dave
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



From clattner at apple.com  Tue Jun 16 23:06:24 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 16 Jun 2009 23:06:24 -0700
Subject: [LLVMdev] Regular Expressions
In-Reply-To: <200906161949.47079.dag@cray.com>
References: <200906081700.n58H0Zvi022899@zion.cs.uiuc.edu>
	<09C9C325-2B00-4C3F-8A11-93FC60B2BDB4@apple.com>
	<200906161935.52304.dag@cray.com> <200906161949.47079.dag@cray.com>
Message-ID: <6075EAC5-AFD5-4239-9ACD-CEDB449CE576@apple.com>


On Jun 16, 2009, at 5:49 PM, David Greene wrote:

> On Tuesday 16 June 2009 19:35, David Greene wrote:
>
>> So which is more intuitive and less error-prone?
>>
>> defm BLENDPS  :  
>> sse41_avx_fp_binary_vector_osta_vintrinsic_rmi_rrmi<0x0C,
>>                  i32i8imm, "blend", "blend", "f32", 4>;
>>
>> or
>>
>> defm BLENDPS  :  
>> sse41_avx_fp_binary_vector_osta_vintrinsic_rmi_rrmi<0x0C,
>>                  i32i8imm, "blendps", "blendps">;
>
> Here's another option:
>
> defm BLENDPS  :  
> sse41_avx_fp_binary_vector_osta_vintrinsic_rmi_rrmi<0x0C,
>                   i32i8imm, "blendps", "blendps", v4f32, v8f32>;
>
> This is somewhere between the first and second options.  It's not as
> convenient as the second but is more intuitive than the first.  Still,
> looking at some random individual instruction, it wouldn't be  
> immediately
> clear to me what those multiple types mean.  I might think they're  
> source
> and destination types, for example.

I think I understand what you're saying with "munging strings is  
easier".  However, I still don't understand why you can't pass down  
some 'my_f32' instead of '"f32"' and have the defm pull out the right  
fields from my_f32.  The AVX type would be v8f32, the SSE type would  
be v4f32, etc.

More generally, I don't see how strings can be better in any  
circumstance: in any case where you pass down a string, you can pass  
down a def that has fields relating to how you would otherwise munge  
the string, no?

-Chris


From evan.cheng at apple.com  Tue Jun 16 23:07:43 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Tue, 16 Jun 2009 23:07:43 -0700
Subject: [LLVMdev] Using LLVM on an embedded device
In-Reply-To: <ADCE5AA1DF84024C88B9B8A29D9553C6041977CD@mx2.telecom.sna.samsung.com>
References: <ADCE5AA1DF84024C88B9B8A29D9553C6041977CD@mx2.telecom.sna.samsung.com>
Message-ID: <70E930DB-2BF5-473E-B155-6C71B6C96E33@apple.com>


On Jun 16, 2009, at 4:09 PM, Anna Zaks wrote:

> Hi,
>
> I am researching a possibility of running LLVM components (such as  
> JIT) on an embedded device, where the memory footprint and RAM usage  
> are the main concerns. So I was wondering if anyone could share  
> their experience with running LLVM on an embedded device. What is  
> the approximate code footprint that we are looking at? For example,  
> on an x86 with a minimum set of optimizations and with only the x86  
> backend, it seems difficult to get the LLVM JIT occupy less than  
> 5MB. Is there any performance and memory usage data available?

That seems too high. I would think it's more in the 2MB range. How did  
you come about that figure? x86 instruction selector itself is quite  
large due to the complex selection patterns. I would expect ARM's  
footprint to be smaller.

There are ways to reduce memory foot print further. But it will  
require someone to drive the effort. One of the (very rough) idea is  
to switch to a table driven instruction selector.

Evan

>
> Thank you!
> Anna.
>
> _______________________________________________
> 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.llvm.org/pipermail/llvm-dev/attachments/20090616/778e302c/attachment.html>

From clattner at apple.com  Tue Jun 16 23:37:04 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 16 Jun 2009 23:37:04 -0700
Subject: [LLVMdev] Upcoming API change: FAdd, FSub, FMul
In-Reply-To: <BBF63352-A55A-4EF9-AB08-66B85AC6B841@apple.com>
References: <BBF63352-A55A-4EF9-AB08-66B85AC6B841@apple.com>
Message-ID: <99E756D4-570A-4735-9508-ADCFC4245DD6@apple.com>


On Jun 15, 2009, at 4:23 PM, Dan Gohman wrote:

> Hello,
>
> The LLVM IR opcodes Add, Sub, and Mul have been each split into
> two.  Add, Sub, and Mul now only handle integer types, and three
> new opcodes, FAdd, FSub, and FMul now handle floating-point types.
>
> The main LLVM APIs are currently preserving backwards
> compatibility, transparently mapping integer opcodes to
> corresponding floating-point opcodes when the operands have
> floating-point types. This compatibility code will eventually be
> removed, so front-end writers should update their front-ends to
> use the new opcodes.  I've updated llvm-gcc as an example.

Thanks Dan, fwiw, I updated clang.

-Chris


From sanjiv.gupta at microchip.com  Tue Jun 16 23:45:02 2009
From: sanjiv.gupta at microchip.com (Sanjiv Gupta)
Date: Wed, 17 Jun 2009 12:15:02 +0530
Subject: [LLVMdev] Localizing Globals ?
In-Reply-To: <f5aa3e9b0906162125p77bd83dfpfa5ee7468b359922@mail.gmail.com>
References: <4A376756.9010302@microchip.com>	<f5aa3e9b0906160310y223ae6d7ve0842397b7f2594c@mail.gmail.com>	<4A386D39.2020404@microchip.com>
	<f5aa3e9b0906162125p77bd83dfpfa5ee7468b359922@mail.gmail.com>
Message-ID: <4A3890EE.6080303@microchip.com>


>> But then such an optimization may fail the entire idea of user wanting to
>> place a variable into different memory space. The original idea of user
>> might be to save on the stack space (data memory) and hence he asked the
>> variable to be placed into different memory space (program memory). So the
>> best bet here is to deny this optimization by checking
>>
>> GV->getType()->getAddressSpace() == 0.
>>     
>
> Yeah, that sounds good; mind putting together a patch?
>
> -Eli
>
>   
Checked in.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   



From suigintou_ at hotmail.com  Tue Jun 16 23:52:57 2009
From: suigintou_ at hotmail.com (seventh moon)
Date: Wed, 17 Jun 2009 14:52:57 +0800
Subject: [LLVMdev] possible PowerPC (32bits) backend bug
Message-ID: <BAY114-W33B8BBA6C8B7D8BA112427F13C0@phx.gbl>


I have been doing some playing with the patterns that define complex
instructions, and I saw a behavior that doesn't look right.
I think its a bug in the PPC backend.

 

The 32-bit PPC .td file defines a pattern for the fnmsubs instruction like this:

 

def : Pat<(fsub F4RC:$B, (fmul F4RC:$A, F4RC:$C)),
          (FNMSUBS F4RC:$A, F4RC:$C, F4RC:$B)>,
          Requires<[FPContractions]>;

 

The unique feature of this parttern is that it maps a pair of
LLVM IR instructions into a single PPC instruction.

 

def FNMSUBS : AForm_1<59, 30,(outs F4RC:$FRT), (ins F4RC:$FRA, F4RC:$FRC, F4RC:$FRB),
                    "fnmsubs $FRT, $FRA, $FRC, $FRB", FPGeneral,
                    [(set F4RC:$FRT, (fneg (fsub (fmul F4RC:$FRA, F4RC:$FRC),F4RC:$FRB)))]>,
                    Requires<[FPContractions]>;

 

Now I wrote a little toy program that, when compiled, uses this instruction.
Here is the program:

#include<stdio.h>

int main()
{
  float a,b,c;
  b = b * c;
  a = a - b;
  return 0;
}


And here is the assembly:


<Insert the pPPC assembly here>
 .text
 .global main
 .type main, @function
 .align 2
main:
 lfs 0, -8(1)
 lfs 1, -12(1)
 li 3, 0
 fmuls 2, 1, 0
 stfs 2, -12(1)
 lfs 2, -16(1)
 fnmsubs 0, 1, 0, 2
 stfs 0, -16(1)
 stw 3, -20(1)
 stw 3, -4(1)
BB1_1: # return
 lwz 3, -4(1)
 blr 
 .size main,.-main

 

At a glance, it looks right. Line 12 is, indeed the "fnmsubs" command, so 
the pattern did work. But look at Line 9. Here we see that the "fmuls" 
also happened! In effect, this means that the fmul happens TWICE.

 

That can't be right can it? Unfortunately, I don't have a PPC emulator, 
so I can't run the code and see if it actually works or not.  
But it does not look right to me.

 

It is a problem, right? Is there any solution? Because I would like to 
also use multiple-IR patterns, for the backend I am working on.

 

Thank you for your assistance,
Kao Chang


_________________________________________________________________
下載 Windows Live Messenger 9.0，多元溝通、盡情分享，和即時傳訊好友線上同樂！— 立即下載
http://download.live.com/messenger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090617/2ce1f9b3/attachment.html>

From eli.friedman at gmail.com  Wed Jun 17 00:02:26 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Wed, 17 Jun 2009 00:02:26 -0700
Subject: [LLVMdev] possible PowerPC (32bits) backend bug
In-Reply-To: <BAY114-W33B8BBA6C8B7D8BA112427F13C0@phx.gbl>
References: <BAY114-W33B8BBA6C8B7D8BA112427F13C0@phx.gbl>
Message-ID: <f5aa3e9b0906170002t3186f347oc81e8e14a4b53722@mail.gmail.com>

2009/6/16 seventh moon <suigintou_ at hotmail.com>:
> At a glance, it looks right. Line 12 is, indeed the "fnmsubs" command, so
> the pattern did work. But look at Line 9. Here we see that the "fmuls"
> also happened! In effect, this means that the fmul happens TWICE.
>
> That can't be right can it? Unfortunately, I don't have a PPC emulator,
> so I can't run the code and see if it actually works or not.
> But it does not look right to me.

I suppose it isn't ideal, but it isn't really bad: the results of both
the fmuls and the fnmsubs instructions are used.

> It is a problem, right? Is there any solution? Because I would like to
> also use multiple-IR patterns, for the backend I am working on.

You can explicitly check that there's only a single use of a node if
you want; for example, see and_su in X86InstInfo.td.

-Eli


From baldrick at free.fr  Wed Jun 17 00:45:01 2009
From: baldrick at free.fr (Duncan Sands)
Date: Wed, 17 Jun 2009 09:45:01 +0200
Subject: [LLVMdev] SSI and ABCD for LLVM
In-Reply-To: <4A37F895.5080209@dcc.ufmg.br>
References: <4A27D078.807@dcc.ufmg.br>	<4A28170A.3020204@lip6.fr>	<1244161343.3936.1.camel@haohui-laptop>	<4A2875E3.9070706@dcc.ufmg.br>	<4a292afe.04015a0a.5436.2327@mx.google.com>	<16517D08-D112-4764-9FE6-91B37DE26857@cs.uiuc.edu>
	<4A37F895.5080209@dcc.ufmg.br>
Message-ID: <4A389EFD.3060007@free.fr>

Hi André,

> we chose ABCD because it is a fast approach to solve the problem. It has 
> the drawback that it is intra-procedural. For the Summer of Code 
> project, we will stick to the original ABCD algorithm. But we can study 
> modifications to make it inter-procedural for later research. Any ideas 
> and contributions you might have will be welcome.

there is a plan to replace the zext and sext parameter attributes with
attributes that tell you how many top bits are zero / sign extended.
For example, if an i32 parameter is marked with the "zext from i27"
attribute that means that the upper 5 bits are always zero.  Your
proposed pass to calculate which bits are in use could both use this
information and calculate it.  This is also gives some info useful
for bounds checking.  It might also be useful to extend these attributes
to give more precise range information on parameters.  Then the ABCD
algorithm could set and use them, giving a cheap form of
inter-procedural ABCD.

Ciao,

Duncan.


From avuori at cs.Helsinki.FI  Wed Jun 17 01:16:48 2009
From: avuori at cs.Helsinki.FI (A. Vuori)
Date: Wed, 17 Jun 2009 11:16:48 +0300 (EEST)
Subject: [LLVMdev] Why are functions renamed for .cpp files with llvm-gcc?
Message-ID: <Pine.LNX.4.64.0906171101590.29818@melkki.cs.Helsinki.FI>

Hello,

I wonder why there is a difference in how 
llvm-gcc compiles .c and .cpp files.

Example:

---bar.cpp----
int bar() {
    return 42;
}
--------------

$ llvm-gcc -emit-llvm -c bar.cpp

Now running bar.o through llvm-dis gives:
--------------------------------
define i32 @_Z3barv() nounwind {
 < clip >
}
--------------------------------

Above, function 'bar' has been renamed to '_Z3barv'.

If, however, 'bar.cpp' is renamed 'bar.c',
we get 'define i32 @bar()' as expected.

I'm currently running precompiled llvm-gcc binaries (being 
unable to compile fresh llvm-gcc at the moment):
llvm-gcc (GCC) 4.2.1 (Based on Apple Inc. build 5623) (LLVM build 2.4).

I apologize if the issue is due to my old llvm-gcc version.

-- 
Arto Vuori


From fabian.scheler at gmail.com  Wed Jun 17 01:39:56 2009
From: fabian.scheler at gmail.com (Fabian Scheler)
Date: Wed, 17 Jun 2009 10:39:56 +0200
Subject: [LLVMdev] Why are functions renamed for .cpp files with
	llvm-gcc?
In-Reply-To: <Pine.LNX.4.64.0906171101590.29818@melkki.cs.Helsinki.FI>
References: <Pine.LNX.4.64.0906171101590.29818@melkki.cs.Helsinki.FI>
Message-ID: <69dd805e0906170139u1afbe938i445f1dec5b4c4324@mail.gmail.com>

Hi Arto,

> I wonder why there is a difference in how
> llvm-gcc compiles .c and .cpp files.
>
> Example:
>
> ---bar.cpp----
> int bar() {
>    return 42;
> }
> --------------
>
> $ llvm-gcc -emit-llvm -c bar.cpp
>
> Now running bar.o through llvm-dis gives:
> --------------------------------
> define i32 @_Z3barv() nounwind {
>  < clip >
> }
> --------------------------------
>
> Above, function 'bar' has been renamed to '_Z3barv'.
>
> If, however, 'bar.cpp' is renamed 'bar.c',
> we get 'define i32 @bar()' as expected.

The answer is: C++ name mangling

Ciao, Fabian


From pertti.kellomaki at tut.fi  Wed Jun 17 02:01:02 2009
From: pertti.kellomaki at tut.fi (=?ISO-8859-1?Q?Pertti_Kellom=E4ki?=)
Date: Wed, 17 Jun 2009 12:01:02 +0300
Subject: [LLVMdev] Why are functions renamed for .cpp files with
	llvm-gcc?
In-Reply-To: <Pine.LNX.4.64.0906171101590.29818@melkki.cs.Helsinki.FI>
References: <Pine.LNX.4.64.0906171101590.29818@melkki.cs.Helsinki.FI>
Message-ID: <4A38B0CE.5080402@tut.fi>

A. Vuori kirjoitti:
> I wonder why there is a difference in how 
> llvm-gcc compiles .c and .cpp files.
[...]
> Above, function 'bar' has been renamed to '_Z3barv'.
> 
> If, however, 'bar.cpp' is renamed 'bar.c',
> we get 'define i32 @bar()' as expected.

Look at what c++filt says about _Z3barv:

$ c++filt _Z3barv
bar()

The reason is that .cpp is taken to be a C++ file, and
names are mangled accordingly.
-- 
Pertti


From st at invia.fr  Wed Jun 17 02:01:56 2009
From: st at invia.fr (Sylvere Teissier)
Date: Wed, 17 Jun 2009 11:01:56 +0200
Subject: [LLVMdev] Why are functions renamed for .cpp files
	with	llvm-gcc?
In-Reply-To: <Pine.LNX.4.64.0906171101590.29818@melkki.cs.Helsinki.FI>
References: <Pine.LNX.4.64.0906171101590.29818@melkki.cs.Helsinki.FI>
Message-ID: <1245229317.6797.5.camel@vostro-1510.invia>

Le mercredi 17 juin 2009 à 11:16 +0300, A. Vuori a écrit :
> Hello,
> 
> I wonder why there is a difference in how 
> llvm-gcc compiles .c and .cpp files.

C++ support function overloading, C not.
For C++ you have to encode the types with the function name to not have
name collision





From resistor at mac.com  Wed Jun 17 02:04:49 2009
From: resistor at mac.com (Owen Anderson)
Date: Wed, 17 Jun 2009 02:04:49 -0700
Subject: [LLVMdev] Why are functions renamed for .cpp files
	with	llvm-gcc?
In-Reply-To: <69dd805e0906170139u1afbe938i445f1dec5b4c4324@mail.gmail.com>
References: <Pine.LNX.4.64.0906171101590.29818@melkki.cs.Helsinki.FI>
	<69dd805e0906170139u1afbe938i445f1dec5b4c4324@mail.gmail.com>
Message-ID: <8645D45C-7D29-4595-BDC4-BB3D9571DAAF@mac.com>


On Jun 17, 2009, at 1:39 AM, Fabian Scheler wrote:

> Hi Arto,
>
>> I wonder why there is a difference in how
>> llvm-gcc compiles .c and .cpp files.
>>
>> Example:
>>
>> ---bar.cpp----
>> int bar() {
>>   return 42;
>> }
>> --------------
>>
>> $ llvm-gcc -emit-llvm -c bar.cpp
>>
>> Now running bar.o through llvm-dis gives:
>> --------------------------------
>> define i32 @_Z3barv() nounwind {
>> < clip >
>> }
>> --------------------------------
>>
>> Above, function 'bar' has been renamed to '_Z3barv'.
>>
>> If, however, 'bar.cpp' is renamed 'bar.c',
>> we get 'define i32 @bar()' as expected.
>
> The answer is: C++ name mangling


To elaborate a little bit, it's how C++ encodes namespaces, function  
overloading, etc.  It's a standard thing, and necessary for cross- 
compiler compatibility.  If you want your C++ functions to appear like  
C functions, you need to use extern "C" { }

--Owen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2620 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090617/0f74cceb/attachment.bin>

From fvbommel at wxs.nl  Wed Jun 17 02:12:39 2009
From: fvbommel at wxs.nl (Frits van Bommel)
Date: Wed, 17 Jun 2009 11:12:39 +0200
Subject: [LLVMdev] Why are functions renamed for .cpp files with
	llvm-gcc?
In-Reply-To: <Pine.LNX.4.64.0906171101590.29818@melkki.cs.Helsinki.FI>
References: <Pine.LNX.4.64.0906171101590.29818@melkki.cs.Helsinki.FI>
Message-ID: <4A38B387.50009@wxs.nl>

A. Vuori wrote:
> Above, function 'bar' has been renamed to '_Z3barv'.
> 
> If, however, 'bar.cpp' is renamed 'bar.c',
> we get 'define i32 @bar()' as expected.

This is not llvm-gcc specific; it happens for regular gcc too. It's needed to 
support overloading multiple functions called 'bar' with different parameters, 
(which C++ supports but C does not). _Z3barv just means "bar()", i.e. a function 
named 'bar' with no parameters (there's a program called c++filt to demangle 
these names).

This is called name mangling. See also 
http://en.wikipedia.org/wiki/Name_mangling#Name_mangling_in_C.2B.2B


From Matthieu.Moy at imag.fr  Wed Jun 17 02:21:41 2009
From: Matthieu.Moy at imag.fr (Matthieu Moy)
Date: Wed, 17 Jun 2009 11:21:41 +0200
Subject: [LLVMdev] Why are functions renamed for .cpp files with
	llvm-gcc?
In-Reply-To: <69dd805e0906170139u1afbe938i445f1dec5b4c4324@mail.gmail.com>
	(Fabian Scheler's message of "Wed\, 17 Jun 2009 10\:39\:56 +0200")
References: <Pine.LNX.4.64.0906171101590.29818@melkki.cs.Helsinki.FI>
	<69dd805e0906170139u1afbe938i445f1dec5b4c4324@mail.gmail.com>
Message-ID: <vpqvdmv1ahm.fsf@bauges.imag.fr>

Fabian Scheler <fabian.scheler at gmail.com> writes:

> The answer is: C++ name mangling

and the slightly longer answer is :

try

int foo(int x) { ... }
int foo(void) { ... }
int foo(whatever-else y) { ... }

(which doesn't compile in C)

-- 
Matthieu


From st at invia.fr  Wed Jun 17 02:43:05 2009
From: st at invia.fr (Sylvere Teissier)
Date: Wed, 17 Jun 2009 11:43:05 +0200
Subject: [LLVMdev] Mailing List lag
In-Reply-To: <4A38B387.50009@wxs.nl>
References: <Pine.LNX.4.64.0906171101590.29818@melkki.cs.Helsinki.FI>
	<4A38B387.50009@wxs.nl>
Message-ID: <1245231785.6797.11.camel@vostro-1510.invia>

I think there is a latency problem with the mail server.
That create answer echo :D


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



From avuori at cs.Helsinki.FI  Wed Jun 17 02:55:09 2009
From: avuori at cs.Helsinki.FI (A. Vuori)
Date: Wed, 17 Jun 2009 12:55:09 +0300 (EEST)
Subject: [LLVMdev] Why are functions renamed for .cpp
	files	with	llvm-gcc?
In-Reply-To: <8645D45C-7D29-4595-BDC4-BB3D9571DAAF@mac.com>
References: <Pine.LNX.4.64.0906171101590.29818@melkki.cs.Helsinki.FI>
	<69dd805e0906170139u1afbe938i445f1dec5b4c4324@mail.gmail.com>
	<8645D45C-7D29-4595-BDC4-BB3D9571DAAF@mac.com>
Message-ID: <Pine.LNX.4.64.0906171254070.29818@melkki.cs.Helsinki.FI>

On Wed, 17 Jun 2009, Owen Anderson wrote:

> To elaborate a little bit, it's how C++ encodes namespaces, function
> overloading, etc.  It's a standard thing, and necessary for cross-compiler
> compatibility.  If you want your C++ functions to appear like C functions, you
> need to use extern "C" { }

Thanks to all for elaborating. So this was just a hole in my C++
knowledge.

-- 
Arto Vuori


From fvbommel at wxs.nl  Wed Jun 17 03:52:05 2009
From: fvbommel at wxs.nl (Frits van Bommel)
Date: Wed, 17 Jun 2009 12:52:05 +0200
Subject: [LLVMdev] Mailing List lag
In-Reply-To: <1245231785.6797.11.camel@vostro-1510.invia>
References: <Pine.LNX.4.64.0906171101590.29818@melkki.cs.Helsinki.FI>	<4A38B387.50009@wxs.nl>
	<1245231785.6797.11.camel@vostro-1510.invia>
Message-ID: <4A38CAD5.7030703@wxs.nl>

Sylvere Teissier wrote:
> I think there is a latency problem with the mail server.
> That create answer echo :D

Yeah, I've noticed that before...


From aaronngray.lists at googlemail.com  Wed Jun 17 06:16:31 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Wed, 17 Jun 2009 14:16:31 +0100
Subject: [LLVMdev] How do I force a complete build ?
Message-ID: <19913F1EF7CB44559C3FBCEADA9C84C8@HPLAPTOP>

How do I make 'make tools-only' do a complete build, I tried '-B' flag but that seemed to trigger complete reconfiguration of every makefile, and takes ages.

Many thanks in advance,

Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090617/104f28ef/attachment.html>

From aaronngray.lists at googlemail.com  Wed Jun 17 06:23:50 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Wed, 17 Jun 2009 14:23:50 +0100
Subject: [LLVMdev] How do I force a complete build ?
In-Reply-To: <19913F1EF7CB44559C3FBCEADA9C84C8@HPLAPTOP>
References: <19913F1EF7CB44559C3FBCEADA9C84C8@HPLAPTOP>
Message-ID: <9719867c0906170623l36ef3e9dpfdef4e491f80bcab@mail.gmail.com>

2009/6/17 Aaron Gray <aaronngray.lists at googlemail.com>

>  How do I make 'make tools-only' do a complete build, I tried '-B' flag
> but that seemed to trigger complete reconfiguration of every makefile, and
> takes ages.
>

Ah :-

make clean
make tools-only

The tools-only target does not seem to be in the LLVM Makefile Guide in the
listed Targets.

Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090617/305f5147/attachment.html>

From dag at cray.com  Wed Jun 17 08:00:50 2009
From: dag at cray.com (David Greene)
Date: Wed, 17 Jun 2009 10:00:50 -0500
Subject: [LLVMdev] Loop alignment
In-Reply-To: <801B1023-8F24-4121-99D1-69915EC5B344@apple.com>
References: <200906161652.39447.dag@cray.com>
	<801B1023-8F24-4121-99D1-69915EC5B344@apple.com>
Message-ID: <200906171000.50936.dag@cray.com>

On Wednesday 17 June 2009 00:11, Evan Cheng wrote:
> Asm printer.

Yes, but where?  I can't find it.  What do I need to
search for?

                           -Dave


From aaronngray.lists at googlemail.com  Wed Jun 17 08:34:31 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Wed, 17 Jun 2009 16:34:31 +0100
Subject: [LLVMdev] Loop alignment
References: <200906161652.39447.dag@cray.com><801B1023-8F24-4121-99D1-69915EC5B344@apple.com>
	<200906171000.50936.dag@cray.com>
Message-ID: <C09E8730B96B453FBE3328A8F973E0D6@HPLAPTOP>

> On Wednesday 17 June 2009 00:11, Evan Cheng wrote:
>> Asm printer.
>
> Yes, but where?  I can't find it.  What do I need to
> search for?

ViewVC is helpful :-

    http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/AsmPrinter/

Look at the X86IntelAsmPrinter.cpp file for code outputting the align, if 
its not there it maybe in the X86AsmPrinter.cpp file, meaning you may have 
to override the functionality in the X86AsmPrinter.h and cpp file.

Aaron




From aaronngray.lists at googlemail.com  Wed Jun 17 08:39:56 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Wed, 17 Jun 2009 16:39:56 +0100
Subject: [LLVMdev] Loop alignment
In-Reply-To: <C09E8730B96B453FBE3328A8F973E0D6@HPLAPTOP>
References: <200906161652.39447.dag@cray.com>
	<801B1023-8F24-4121-99D1-69915EC5B344@apple.com> 
	<200906171000.50936.dag@cray.com>
	<C09E8730B96B453FBE3328A8F973E0D6@HPLAPTOP>
Message-ID: <9719867c0906170839p4baf0e8ake20da48db867cca7@mail.gmail.com>

Oh, Theres also stuff in TargetAsmInfo class that may contain the actual
'align' statment.

Look in Target/X86/X86TargetAsmInfo.[cpp,h]

Aaron

2009/6/17 Aaron Gray <aaronngray.lists at googlemail.com>

>  On Wednesday 17 June 2009 00:11, Evan Cheng wrote:
>>
>>> Asm printer.
>>>
>>
>> Yes, but where?  I can't find it.  What do I need to
>> search for?
>>
>
> ViewVC is helpful :-
>
>
> http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/AsmPrinter/
>
> Look at the X86IntelAsmPrinter.cpp file for code outputting the align, if
> its not there it maybe in the X86AsmPrinter.cpp file, meaning you may have
> to override the functionality in the X86AsmPrinter.h and cpp file.
>
> Aaron
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090617/1aa7e9f5/attachment.html>

From juanc.martinez.santos at gmail.com  Wed Jun 17 09:10:40 2009
From: juanc.martinez.santos at gmail.com (Juan Carlos Martinez Santos)
Date: Wed, 17 Jun 2009 12:10:40 -0400
Subject: [LLVMdev] Segmentation fault - Kaleidoscope
Message-ID: <d17b77a40906170910h607175bcm6d51a23e0e11db6c@mail.gmail.com>

Hello,

Following the tutorial "Kaleidoscope: Adding JIT and Optimizer Support", I
found a Segmentation fault when I try to execute it. I am new in the
neighbourhood, so I don't know what is wrong. Could you help me with that?

I am working with the last version of LLVM (2.5). The code in chapter 2 and
3 works good, but the code in the chapter 4 did not work.

Below are the detail of what I did.

Regards,

Juan Carlos

*********************************
http://llvm.org/docs/tutorial/LangImpl4.html#jit

*********************************
./toy
ready> 4+5;
Segmentation fault

*********************************
Details using gdb:
*********************************
[New Thread 0xb7ca96c0 (LWP 9948)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7ca96c0 (LWP 9948)]
0x0804e914 in main ()
    at /usr/local/include/llvm/ExecutionEngine/ExecutionEngine.h:142
142      const TargetData *getTargetData() const { return TD; }


-- 
Juan Carlos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090617/0657143f/attachment.html>

From clattner at apple.com  Wed Jun 17 09:15:51 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 17 Jun 2009 09:15:51 -0700
Subject: [LLVMdev] possible PowerPC (32bits) backend bug
In-Reply-To: <BAY114-W33B8BBA6C8B7D8BA112427F13C0@phx.gbl>
References: <BAY114-W33B8BBA6C8B7D8BA112427F13C0@phx.gbl>
Message-ID: <35D88922-8CB1-4353-8BD8-7D74B6C16696@apple.com>

On Jun 16, 2009, at 11:52 PM, seventh moon wrote:
> At a glance, it looks right. Line 12 is, indeed the "fnmsubs"  
> command, so
> the pattern did work. But look at Line 9. Here we see that the "fmuls"
> also happened! In effect, this means that the fmul happens TWICE.
>
> That can't be right can it? Unfortunately, I don't have a PPC  
> emulator,
> so I can't run the code and see if it actually works or not.
> But it does not look right to me.
>

The code is correct.  The mul is being multiply evaluated because  
you're looking at -O0 code, try an equivalent example with -O2 or  
something.

-Chris


From llvm at assumetheposition.nl  Wed Jun 17 09:46:03 2009
From: llvm at assumetheposition.nl (Paul Melis)
Date: Wed, 17 Jun 2009 18:46:03 +0200
Subject: [LLVMdev] Segmentation fault - Kaleidoscope
In-Reply-To: <d17b77a40906170910h607175bcm6d51a23e0e11db6c@mail.gmail.com>
References: <d17b77a40906170910h607175bcm6d51a23e0e11db6c@mail.gmail.com>
Message-ID: <4A391DCB.8070307@assumetheposition.nl>

FWIW, I'm also suddenly experiencing segfaults in code that used to work
a few days ago (I'm using svn). This may be unrelated to the problem
described below, but perhaps it's the same thing.

In my case it seems that creating an ExecutionEngine has changed. I used
to do

    Module* Mod = makeLLVMModule();      // basically create a gcd function
    verifyModule(*Mod, PrintMessageAction);

    ExecutionEngine *EE;
    EE = ExecutionEngine::create(Mod);

but I now get 0x0 for EE. The compile command I'm using is

g++ -O3 -I ~/llvm/include/ -L ~/llvm bug.cpp `llvm-config --cxxflags
--ldflags --libs core jit native` -o bug

I noticed something very recently changed w.r.t. the way LLVM's
libraries are built (no more .o files). Could this have something to
with it?

Regards,
Paul


Juan Carlos Martinez Santos wrote:
> Hello,
>
> Following the tutorial "Kaleidoscope: Adding JIT and Optimizer
> Support", I found a Segmentation fault when I try to execute it. I am
> new in the neighbourhood, so I don't know what is wrong. Could you
> help me with that?
>
> I am working with the last version of LLVM (2.5). The code in chapter
> 2 and 3 works good, but the code in the chapter 4 did not work.
>
> Below are the detail of what I did.
>
> Regards,
>
> Juan Carlos
>
> *********************************
> http://llvm.org/docs/tutorial/LangImpl4.html#jit
>
> *********************************
> ./toy
> ready> 4+5;
> Segmentation fault
>
> *********************************
> Details using gdb:
> *********************************
> [New Thread 0xb7ca96c0 (LWP 9948)]
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0xb7ca96c0 (LWP 9948)]
> 0x0804e914 in main ()
>     at /usr/local/include/llvm/ExecutionEngine/ExecutionEngine.h:142
> 142      const TargetData *getTargetData() const { return TD; }
>
>
> -- 
> Juan Carlos
> ------------------------------------------------------------------------
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   



From clattner at apple.com  Wed Jun 17 09:51:37 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 17 Jun 2009 09:51:37 -0700
Subject: [LLVMdev] Segmentation fault - Kaleidoscope
In-Reply-To: <4A391DCB.8070307@assumetheposition.nl>
References: <d17b77a40906170910h607175bcm6d51a23e0e11db6c@mail.gmail.com>
	<4A391DCB.8070307@assumetheposition.nl>
Message-ID: <24361044-96E1-4490-A7B6-31A4E097CB46@apple.com>


On Jun 17, 2009, at 9:46 AM, Paul Melis wrote:

> FWIW, I'm also suddenly experiencing segfaults in code that used to  
> work
> a few days ago (I'm using svn). This may be unrelated to the problem
> described below, but perhaps it's the same thing.
>
> In my case it seems that creating an ExecutionEngine has changed. I  
> used
> to do
>
>    Module* Mod = makeLLVMModule();      // basically create a gcd  
> function
>    verifyModule(*Mod, PrintMessageAction);
>
>    ExecutionEngine *EE;
>    EE = ExecutionEngine::create(Mod);
>
> but I now get 0x0 for EE. The compile command I'm using is
>
> g++ -O3 -I ~/llvm/include/ -L ~/llvm bug.cpp `llvm-config --cxxflags
> --ldflags --libs core jit native` -o bug
>
> I noticed something very recently changed w.r.t. the way LLVM's
> libraries are built (no more .o files). Could this have something to
> with it?

I *just* changed this. :)

For JIT applications, please include llvm/Target/TargetSelect.h and  
call the llvm::InitializeNativeTarget() function before creating an EE.

-Chris


From sean.ysl at gmail.com  Wed Jun 17 10:03:08 2009
From: sean.ysl at gmail.com (Sean Lee)
Date: Wed, 17 Jun 2009 10:03:08 -0700
Subject: [LLVMdev] CMake does not work with LLVM anymore?
Message-ID: <856192540906171003k6852c963md8088fe6367f50a0@mail.gmail.com>

Hi,

I am just letting you know that I have not been able to build LLVM
using CMake since I ran svn up yesterday.
And it would be great if somebody could tell me whether the problem is
on my end.

What I did was,

~/llvm$ svn up

~/llvm$ mkdir cmakebuild

~/llvm$ cd cmakebuild

~/llvm/cmakebuild$ cmake -DCMAKE_BUILD_TYPE:STRING="Release"
-DLLVM_TARGETS_TO_BUILD:STRING="X86" ..
-- Target triple:
-- LLVM_HOSTTRIPLE: i686-pc-linux-gnu
-- Threads enabled.
-- Targeting X86
-- Target triple:
-- Configuring done
-- Generating done
-- Build files have been written to: /home/selee/llvm/cmakebuild

~/llvm/cmakebuild$ make

After awhile, I got the following error message and couldn't complete the build.

../../lib/libLLVMCore.a(Type.cpp.o): In function
`llvm::IntegerType::get(unsigned int)':
Type.cpp:(.text+0x394c): undefined reference to
`llvm::sys::RWMutex::reader_acquire()'
Type.cpp:(.text+0x397a): undefined reference to
`llvm::sys::RWMutex::reader_release()'
Type.cpp:(.text+0x3a7f): undefined reference to
`llvm::sys::RWMutex::writer_acquire()'
Type.cpp:(.text+0x3ab1): undefined reference to
`llvm::sys::RWMutex::writer_release()'
../../lib/libLLVMCore.a(Type.cpp.o): In function
`llvm::DerivedType::refineAbstractTypeTo(llvm::Type const*)':
Type.cpp:(.text+0x3ce0): undefined reference to
`llvm::sys::RWMutex::writer_acquire()'
../../lib/libLLVMCore.a(Type.cpp.o): In function
`llvm::StructType::get(std::vector<llvm::Type const*,
std::allocator<llvm::Type const*> > const&, bool)':
Type.cpp:(.text+0x3f76): undefined reference to
`llvm::sys::RWMutex::reader_acquire()'
Type.cpp:(.text+0x3fb0): undefined reference to
`llvm::sys::RWMutex::reader_release()'
Type.cpp:(.text+0x4090): undefined reference to
`llvm::sys::RWMutex::writer_acquire()'
Type.cpp:(.text+0x40c2): undefined reference to
`llvm::sys::RWMutex::writer_release()'
../../lib/libLLVMCore.a(Type.cpp.o): In function
`llvm::FunctionType::get(llvm::Type const*, std::vector<llvm::Type
const*, std::allocator<llvm::Type const*> > const&, bool)':
Type.cpp:(.text+0x42cc): undefined reference to
`llvm::sys::RWMutex::reader_acquire()'
Type.cpp:(.text+0x4309): undefined reference to
`llvm::sys::RWMutex::reader_release()'
Type.cpp:(.text+0x43f8): undefined reference to
`llvm::sys::RWMutex::writer_acquire()'
Type.cpp:(.text+0x442a): undefined reference to
`llvm::sys::RWMutex::writer_release()'
../../lib/libLLVMCore.a(Type.cpp.o): In function
`llvm::ArrayType::get(llvm::Type const*, unsigned long long)':
Type.cpp:(.text+0x4574): undefined reference to
`llvm::sys::RWMutex::reader_acquire()'
Type.cpp:(.text+0x4634): undefined reference to
`llvm::sys::RWMutex::reader_release()'
Type.cpp:(.text+0x4780): undefined reference to
`llvm::sys::RWMutex::reader_release()'
Type.cpp:(.text+0x4797): undefined reference to
`llvm::sys::RWMutex::writer_acquire()'
Type.cpp:(.text+0x47cd): undefined reference to
`llvm::sys::RWMutex::writer_release()'
../../lib/libLLVMCore.a(Type.cpp.o): In function
`llvm::VectorType::get(llvm::Type const*, unsigned int)':
Type.cpp:(.text+0x4932): undefined reference to
`llvm::sys::RWMutex::reader_acquire()'
Type.cpp:(.text+0x49c3): undefined reference to
`llvm::sys::RWMutex::reader_release()'
Type.cpp:(.text+0x4ad0): undefined reference to
`llvm::sys::RWMutex::reader_release()'
Type.cpp:(.text+0x4ae7): undefined reference to
`llvm::sys::RWMutex::writer_acquire()'
Type.cpp:(.text+0x4b1d): undefined reference to
`llvm::sys::RWMutex::writer_acquire()'
../../lib/libLLVMCore.a(Type.cpp.o): In function
`llvm::PointerType::get(llvm::Type const*, unsigned int)':
Type.cpp:(.text+0x4c42): undefined reference to
`llvm::sys::RWMutex::reader_acquire()'
Type.cpp:(.text+0x4cd3): undefined reference to
`llvm::sys::RWMutex::reader_release()'
Type.cpp:(.text+0x4de0): undefined reference to
`llvm::sys::RWMutex::reader_release()'
Type.cpp:(.text+0x4df7): undefined reference to
`llvm::sys::RWMutex::writer_acquire()'
Type.cpp:(.text+0x4e2d): undefined reference to
`llvm::sys::RWMutex::writer_release()'
../../lib/libLLVMCore.a(Type.cpp.o): In function
`llvm::DerivedType::refineAbstractTypeTo(llvm::Type const*)':
Type.cpp:(.text+0x3d09): undefined reference to
`llvm::sys::RWMutex::writer_release()'
../../lib/libLLVMCore.a(Type.cpp.o): In function `void
llvm::object_deleter<llvm::sys::RWMutex>(void*)':
Type.cpp:(.text._ZN4llvm14object_deleterINS_3sys7RWMutexEEEvPv[void
llvm::object_deleter<llvm::sys::RWMutex>(void*)]+0x12): undefined
reference to `llvm::sys::RWMutex::~RWMutex()'
../../lib/libLLVMCore.a(Type.cpp.o): In function `void*
llvm::object_creator<llvm::sys::RWMutex>()':
Type.cpp:(.text._ZN4llvm14object_creatorINS_3sys7RWMutexEEEPvv[void*
llvm::object_creator<llvm::sys::RWMutex>()]+0x1e): undefined reference
to `llvm::sys::RWMutex::RWMutex()'
collect2: ld returned 1 exit status
make[2]: *** [bin/opt] Error 1
make[1]: *** [tools/opt/CMakeFiles/opt.dir/all] Error 2
make: *** [all] Error 2

It seems that RWMutex has been added to the source tree yesterday, and
some source code files have been modified accordingly.

Thanks,
Sean

-- 
Sean Lee
PhD Student
Programming Language and Systems Research Group
School of Computer Science and Engineering
University of New South Wales
http://www.cse.unsw.edu.au/~seanl


From aaronngray.lists at googlemail.com  Wed Jun 17 10:19:21 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Wed, 17 Jun 2009 18:19:21 +0100
Subject: [LLVMdev] CMake does not work with LLVM anymore?
References: <856192540906171003k6852c963md8088fe6367f50a0@mail.gmail.com>
Message-ID: <FBC859B3D9054EAB86A35667803A3B49@HPLAPTOP>

> I am just letting you know that I have not been able to build LLVM
> using CMake since I ran svn up yesterday.
> And it would be great if somebody could tell me whether the problem is
> on my end.
>
> What I did was,
>
> ~/llvm$ svn up
>
> ~/llvm$ mkdir cmakebuild
>
> ~/llvm$ cd cmakebuild
>
> ~/llvm/cmakebuild$ cmake -DCMAKE_BUILD_TYPE:STRING="Release"
> -DLLVM_TARGETS_TO_BUILD:STRING="X86" ..
> -- Target triple:
> -- LLVM_HOSTTRIPLE: i686-pc-linux-gnu
> -- Threads enabled.
> -- Targeting X86
> -- Target triple:
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/selee/llvm/cmakebuild
>
> ~/llvm/cmakebuild$ make
>
> After awhile, I got the following error message and couldn't complete the 
> build.
>
> ../../lib/libLLVMCore.a(Type.cpp.o): In function
> `llvm::IntegerType::get(unsigned int)':
> Type.cpp:(.text+0x394c): undefined reference to
> `llvm::sys::RWMutex::reader_acquire()'

The CMake files need updating

lib/System/RWMutex.cpp needs adding to lib/System/CMakeLists.txt

> It seems that RWMutex has been added to the source tree yesterday, and
> some source code files have been modified accordingly.

Yep.

Aaron



From xerxes at zafena.se  Wed Jun 17 10:33:33 2009
From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=)
Date: Wed, 17 Jun 2009 19:33:33 +0200
Subject: [LLVMdev] Segmentation fault - Kaleidoscope
In-Reply-To: <4A391DCB.8070307@assumetheposition.nl>
References: <d17b77a40906170910h607175bcm6d51a23e0e11db6c@mail.gmail.com>
	<4A391DCB.8070307@assumetheposition.nl>
Message-ID: <4A3928ED.2070903@zafena.se>

Some recent API changes require that the JIT have to be initialized 
before use:

#include "llvm/Target/TargetSelect.h"

and use
// If we have a native target, initialize it to ensure it is linked in and
// usable by the JIT.
InitializeNativeTarget();

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090615/078885.html 


the llvm examples including Kaleidoscope have been changed to use the 
jit in this new way:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090615/078888.html 


this will fix the 0x0 for EE error.

Xerxes

Den 2009-06-17 18:46, Paul Melis skrev:
> FWIW, I'm also suddenly experiencing segfaults in code that used to work
> a few days ago (I'm using svn). This may be unrelated to the problem
> described below, but perhaps it's the same thing.
>
> In my case it seems that creating an ExecutionEngine has changed. I used
> to do
>
>      Module* Mod = makeLLVMModule();      // basically create a gcd function
>      verifyModule(*Mod, PrintMessageAction);
>
>      ExecutionEngine *EE;
>      EE = ExecutionEngine::create(Mod);
>
> but I now get 0x0 for EE. The compile command I'm using is
>
> g++ -O3 -I ~/llvm/include/ -L ~/llvm bug.cpp `llvm-config --cxxflags
> --ldflags --libs core jit native` -o bug
>
> I noticed something very recently changed w.r.t. the way LLVM's
> libraries are built (no more .o files). Could this have something to
> with it?
>
> Regards,
> Paul
>
>
> Juan Carlos Martinez Santos wrote:
>    
>> Hello,
>>
>> Following the tutorial "Kaleidoscope: Adding JIT and Optimizer
>> Support", I found a Segmentation fault when I try to execute it. I am
>> new in the neighbourhood, so I don't know what is wrong. Could you
>> help me with that?
>>
>> I am working with the last version of LLVM (2.5). The code in chapter
>> 2 and 3 works good, but the code in the chapter 4 did not work.
>>
>> Below are the detail of what I did.
>>
>> Regards,
>>
>> Juan Carlos
>>
>> *********************************
>> http://llvm.org/docs/tutorial/LangImpl4.html#jit
>>
>> *********************************
>> ./toy
>> ready>  4+5;
>> Segmentation fault
>>
>> *********************************
>> Details using gdb:
>> *********************************
>> [New Thread 0xb7ca96c0 (LWP 9948)]
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread 0xb7ca96c0 (LWP 9948)]
>> 0x0804e914 in main ()
>>      at /usr/local/include/llvm/ExecutionEngine/ExecutionEngine.h:142
>> 142      const TargetData *getTargetData() const { return TD; }
>>
>>
>> -- 
>> Juan Carlos
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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.llvm.org/pipermail/llvm-dev/attachments/20090617/d4967e52/attachment.html>

From aaronngray.lists at googlemail.com  Wed Jun 17 10:33:51 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Wed, 17 Jun 2009 18:33:51 +0100
Subject: [LLVMdev] how do I run 'make check' on say just the 'test/CodeGen'
	directory ?
Message-ID: <4800536DFF464AB5B031A32F31B26D9B@HPLAPTOP>

Does 'make check' allow just running on a particualar directory of tests ?

Many thanks in advance,

Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090617/e0dc48e4/attachment.html>

From juanc.martinez.santos at gmail.com  Wed Jun 17 10:43:43 2009
From: juanc.martinez.santos at gmail.com (Juan Carlos Martinez Santos)
Date: Wed, 17 Jun 2009 13:43:43 -0400
Subject: [LLVMdev] Segmentation fault - Kaleidoscope
In-Reply-To: <24361044-96E1-4490-A7B6-31A4E097CB46@apple.com>
References: <d17b77a40906170910h607175bcm6d51a23e0e11db6c@mail.gmail.com>
	<4A391DCB.8070307@assumetheposition.nl>
	<24361044-96E1-4490-A7B6-31A4E097CB46@apple.com>
Message-ID: <d17b77a40906171043o610540e0he3247167089cbedb@mail.gmail.com>

Hello,

Maybe my version (LLVM 2.5) is incomplete... now get this error:

toy.cpp:11:38: error: llvm/Target/TargetSelect.h: No such file or directory

How can I get this file?

Regards,

Juan Carlos


On Wed, Jun 17, 2009 at 12:51 PM, Chris Lattner <clattner at apple.com> wrote:

>
> On Jun 17, 2009, at 9:46 AM, Paul Melis wrote:
>
> > FWIW, I'm also suddenly experiencing segfaults in code that used to
> > work
> > a few days ago (I'm using svn). This may be unrelated to the problem
> > described below, but perhaps it's the same thing.
> >
> > In my case it seems that creating an ExecutionEngine has changed. I
> > used
> > to do
> >
> >    Module* Mod = makeLLVMModule();      // basically create a gcd
> > function
> >    verifyModule(*Mod, PrintMessageAction);
> >
> >    ExecutionEngine *EE;
> >    EE = ExecutionEngine::create(Mod);
> >
> > but I now get 0x0 for EE. The compile command I'm using is
> >
> > g++ -O3 -I ~/llvm/include/ -L ~/llvm bug.cpp `llvm-config --cxxflags
> > --ldflags --libs core jit native` -o bug
> >
> > I noticed something very recently changed w.r.t. the way LLVM's
> > libraries are built (no more .o files). Could this have something to
> > with it?
>
> I *just* changed this. :)
>
> For JIT applications, please include llvm/Target/TargetSelect.h and
> call the llvm::InitializeNativeTarget() function before creating an EE.
>
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>



-- 
Juan Carlos Martínez Santos
242 Foster Drive Apt H
Colonial Townhouse Apartments
Willimantic, CT 06226-1538
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090617/e8e71792/attachment.html>

From tonic at nondot.org  Wed Jun 17 10:53:02 2009
From: tonic at nondot.org (Tanya M. Lattner)
Date: Wed, 17 Jun 2009 10:53:02 -0700 (PDT)
Subject: [LLVMdev] how do I run 'make check' on say just the
 'test/CodeGen' directory ?
In-Reply-To: <4800536DFF464AB5B031A32F31B26D9B@HPLAPTOP>
References: <4800536DFF464AB5B031A32F31B26D9B@HPLAPTOP>
Message-ID: <alpine.DEB.2.00.0906171052250.19970@nondot.org>


On Wed, 17 Jun 2009, Aaron Gray wrote:

> Does 'make check' allow just running on a particualar directory of tests ?

make check TESTSUITE=CodeGen

You set TESTSUITE to any directory.

-Tanya

>  
> Many thanks in advance,
>  
> Aaron
>  
> 
>

From stefanus.dutoit at rapidmind.com  Wed Jun 17 10:55:18 2009
From: stefanus.dutoit at rapidmind.com (Stefanus Du Toit)
Date: Wed, 17 Jun 2009 13:55:18 -0400
Subject: [LLVMdev] how do I run 'make check' on say just the
	'test/CodeGen' directory ?
In-Reply-To: <4800536DFF464AB5B031A32F31B26D9B@HPLAPTOP>
References: <4800536DFF464AB5B031A32F31B26D9B@HPLAPTOP>
Message-ID: <25F882D7-72F1-4907-8BEC-5CD1BFAFD3B1@rapidmind.com>

 From http://www.llvm.org/docs/TestingGuide.html#quickdejagnu :

To run only a subdirectory of tests in llvm/test using DejaGNU (ie.  
Transforms), just set the TESTSUITE variable to the path of the  
subdirectory (relative to llvm/test):

% gmake TESTSUITE=Transforms check


On 17-Jun-09, at 1:33 PM, Aaron Gray wrote:
> Does 'make check' allow just running on a particualar directory of  
> tests ?
>
> Many thanks in advance,
>
> Aaron
>  <ATT00001.txt>

--
Stefanus Du Toit <stefanus.dutoit at rapidmind.com>
   RapidMind Inc.
   phone: +1 519 885 5455 x116 -- fax: +1 519 885 1463



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090617/1cd0d414/attachment.html>

From llvm at assumetheposition.nl  Wed Jun 17 11:04:44 2009
From: llvm at assumetheposition.nl (Paul Melis)
Date: Wed, 17 Jun 2009 20:04:44 +0200
Subject: [LLVMdev] Segmentation fault - Kaleidoscope
In-Reply-To: <24361044-96E1-4490-A7B6-31A4E097CB46@apple.com>
References: <d17b77a40906170910h607175bcm6d51a23e0e11db6c@mail.gmail.com>	<4A391DCB.8070307@assumetheposition.nl>
	<24361044-96E1-4490-A7B6-31A4E097CB46@apple.com>
Message-ID: <4A39303C.4060108@assumetheposition.nl>

Chris Lattner wrote:
> On Jun 17, 2009, at 9:46 AM, Paul Melis wrote:
>
>   
>> FWIW, I'm also suddenly experiencing segfaults in code that used to  
>> work
>> a few days ago (I'm using svn). This may be unrelated to the problem
>> described below, but perhaps it's the same thing.
>>
>> In my case it seems that creating an ExecutionEngine has changed. I  
>> used
>> to do
>>
>>    Module* Mod = makeLLVMModule();      // basically create a gcd  
>> function
>>    verifyModule(*Mod, PrintMessageAction);
>>
>>    ExecutionEngine *EE;
>>    EE = ExecutionEngine::create(Mod);
>>
>> but I now get 0x0 for EE. The compile command I'm using is
>>
>> g++ -O3 -I ~/llvm/include/ -L ~/llvm bug.cpp `llvm-config --cxxflags
>> --ldflags --libs core jit native` -o bug
>>
>> I noticed something very recently changed w.r.t. the way LLVM's
>> libraries are built (no more .o files). Could this have something to
>> with it?
>>     
>
> I *just* changed this. :)
>   
Hmm, I can see your commits from a few hours ago, but something was
already up a bit earlier. Anyways...
> For JIT applications, please include llvm/Target/TargetSelect.h and  
> call the llvm::InitializeNativeTarget() function before creating an EE.
>   
I just svn up-ped to r73620, recompiled and reinstalled LLVM and still
got 0x0 for the execution engine instance.
Found the problem: I didn't include "llvm/ExecutionEngine/JIT.h"

Paul



From anton at korobeynikov.info  Wed Jun 17 11:06:56 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Wed, 17 Jun 2009 22:06:56 +0400
Subject: [LLVMdev] how do I run 'make check' on say just the
	'test/CodeGen' directory ?
In-Reply-To: <4800536DFF464AB5B031A32F31B26D9B@HPLAPTOP>
References: <4800536DFF464AB5B031A32F31B26D9B@HPLAPTOP>
Message-ID: <b087fca00906171106s8592479m6424175f824e765a@mail.gmail.com>

> Does 'make check' allow just running on a particualar directory of tests ?
Yes, e.g. make check TESTSUITE=CodeGen/X86

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


From clattner at apple.com  Wed Jun 17 11:45:46 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 17 Jun 2009 11:45:46 -0700
Subject: [LLVMdev] Segmentation fault - Kaleidoscope
In-Reply-To: <d17b77a40906171043o610540e0he3247167089cbedb@mail.gmail.com>
References: <d17b77a40906170910h607175bcm6d51a23e0e11db6c@mail.gmail.com>
	<4A391DCB.8070307@assumetheposition.nl>
	<24361044-96E1-4490-A7B6-31A4E097CB46@apple.com>
	<d17b77a40906171043o610540e0he3247167089cbedb@mail.gmail.com>
Message-ID: <1FF7E1FA-B0C4-449A-8A1E-E86E419113D4@apple.com>


On Jun 17, 2009, at 10:43 AM, Juan Carlos Martinez Santos wrote:

> Hello,
>
> Maybe my version (LLVM 2.5) is incomplete... now get this error:
>
> toy.cpp:11:38: error: llvm/Target/TargetSelect.h: No such file or  
> directory
>
> How can I get this file?

This only exists on mainline.

-Chris



From marks at dcs.gla.ac.uk  Wed Jun 17 12:06:44 2009
From: marks at dcs.gla.ac.uk (Mark Shannon)
Date: Wed, 17 Jun 2009 20:06:44 +0100
Subject: [LLVMdev] Undocumented API changes
In-Reply-To: <24361044-96E1-4490-A7B6-31A4E097CB46@apple.com>
References: <d17b77a40906170910h607175bcm6d51a23e0e11db6c@mail.gmail.com>	<4A391DCB.8070307@assumetheposition.nl>
	<24361044-96E1-4490-A7B6-31A4E097CB46@apple.com>
Message-ID: <4A393EC4.80205@dcs.gla.ac.uk>

Hi,

Why are there so many undocumented (and as I far I can see) unnecessary 
API changes?

Recently there has been:

1.
For JIT applications, please include llvm/Target/TargetSelect.h and
call the llvm::InitializeNativeTarget() function before creating an EE.

2.
The major CHANGE is:  the JIT will no longer be safe for executing
threaded applications without first invoking llvm_start_multithreaded(). 
  Please begin to update your client applications now if this affects 
you, as I will be throwing the switch in SVN sooner rather than later.

3.
The change you should make: every call to addPassesToEmitFile,
addPassesToEmitFileFinish, addPassesToEmitMachineCode, or
addCommonCodeGenPasses should pass an optimization level enum rather
than true / false for "Fast". The enum is in
llvm/Target/TargetMachine.h:

namespace CodeGenOpt {
   enum Level {
     Default,
     None,
     Aggressive
   };
}

4.
The LLVM IR opcodes Add, Sub, and Mul have been each split into two. 
Add, Sub, and Mul now only handle integer types, and three new opcodes, 
FAdd, FSub, and FMul now handle floating-point types.

And that's just in a few days!

I recently tried to build my compiler-generator with the svn-head 
version of llvm.
No chance.
It wouldn't build, thanks to (3) above.
Once I got it to build, it crashed.
It all works just fine with 2.5.

I spent a lot of time and effort, getting things to work, first with 
2.4, then with 2.5 (The changes in the API between 2.4 and 2.5 were more 
than I would have liked, but mainly renaming and caught by the compiler).

Remember, its not just gcc-llvm and clang that use llvm.

So please treat the API with respect.
Don't change it often, and document EACH and EVERY change.

PS.

Change (1) above seems to be pointless.
Why can't the code to create the EE, just call 
llvm::InitializeNativeTarget()?

Mark.



From aaronngray.lists at googlemail.com  Wed Jun 17 12:11:25 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Wed, 17 Jun 2009 20:11:25 +0100
Subject: [LLVMdev] how do I run 'make check' on say just
	the'test/CodeGen' directory ?
References: <4800536DFF464AB5B031A32F31B26D9B@HPLAPTOP>
	<25F882D7-72F1-4907-8BEC-5CD1BFAFD3B1@rapidmind.com>
Message-ID: <CC508C1B121641A6AE49910D7E30EFDD@HPLAPTOP>

Ah, if in doubt read the fine manual :)
  ----- Original Message ----- 
  From: Stefanus Du Toit 
  To: LLVM Developers Mailing List 
  Sent: Wednesday, June 17, 2009 6:55 PM
  Subject: Re: [LLVMdev] how do I run 'make check' on say just the'test/CodeGen' directory ?


  From http://www.llvm.org/docs/TestingGuide.html#quickdejagnu :


  To run only a subdirectory of tests in llvm/test using DejaGNU (ie. Transforms), just set the TESTSUITE variable to the path of the subdirectory (relative to llvm/test):

% gmake TESTSUITE=Transforms check




  On 17-Jun-09, at 1:33 PM, Aaron Gray wrote:
    Does 'make check' allow just running on a particualar directory of tests ?

    Many thanks in advance,

    Aaron
     <ATT00001.txt>


  --
  Stefanus Du Toit <stefanus.dutoit at rapidmind.com>
    RapidMind Inc.
    phone: +1 519 885 5455 x116 -- fax: +1 519 885 1463








------------------------------------------------------------------------------


  _______________________________________________
  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.llvm.org/pipermail/llvm-dev/attachments/20090617/d1c643fa/attachment.html>

From Dr.Graef at t-online.de  Wed Jun 17 12:23:20 2009
From: Dr.Graef at t-online.de (Albert Graef)
Date: Wed, 17 Jun 2009 21:23:20 +0200
Subject: [LLVMdev] Segmentation fault - Kaleidoscope
In-Reply-To: <24361044-96E1-4490-A7B6-31A4E097CB46@apple.com>
References: <d17b77a40906170910h607175bcm6d51a23e0e11db6c@mail.gmail.com>	<4A391DCB.8070307@assumetheposition.nl>
	<24361044-96E1-4490-A7B6-31A4E097CB46@apple.com>
Message-ID: <4A3942A8.2000608@t-online.de>

Chris Lattner wrote:
> For JIT applications, please include llvm/Target/TargetSelect.h and  
> call the llvm::InitializeNativeTarget() function before creating an EE.

Couldn't the EE creation functions do this call automatically if no
target has been set yet, instead of just returning a null pointer? For
the sake of backward compatibility.

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de
WWW:    http://www.musikinformatik.uni-mainz.de/ag


From isanbard at gmail.com  Wed Jun 17 13:00:02 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Wed, 17 Jun 2009 13:00:02 -0700
Subject: [LLVMdev] Undocumented API changes
In-Reply-To: <4A393EC4.80205@dcs.gla.ac.uk>
References: <d17b77a40906170910h607175bcm6d51a23e0e11db6c@mail.gmail.com>
	<4A391DCB.8070307@assumetheposition.nl>
	<24361044-96E1-4490-A7B6-31A4E097CB46@apple.com>
	<4A393EC4.80205@dcs.gla.ac.uk>
Message-ID: <16e5fdf90906171300t552a2f34p9d0d15ce81b8d1ba@mail.gmail.com>

Hi Mark,

> 3.
> The change you should make: every call to addPassesToEmitFile,
> addPassesToEmitFileFinish, addPassesToEmitMachineCode, or
> addCommonCodeGenPasses should pass an optimization level enum rather
> than true / false for "Fast". The enum is in
> llvm/Target/TargetMachine.h:
>
> namespace CodeGenOpt {
>   enum Level {
>     Default,
>     None,
>     Aggressive
>   };
> }
>
We needed a finer-grained control over what optimizations are run
during the code generation passes. Some optimizations aren't
appropriate for the Default case, but are for the Aggressive case.

I can't comment on the other changes. But in general, the llvm
development trunk is in a state of perpetual flux. It only settles
down around release time. Also, our APIs aren't written in stone,
which is by design. The downside of this is that people who use our
APIs may have to change their code from release to release. And if you
live on the development trunk, it takes a lot of maintenance to keep
up (as you found out). We do try to document, or at least warn, about
every change we make. But that documentation tends to be from release
to release.

-bw



From clattner at apple.com  Wed Jun 17 13:00:54 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 17 Jun 2009 13:00:54 -0700
Subject: [LLVMdev] Segmentation fault - Kaleidoscope
In-Reply-To: <4A3942A8.2000608@t-online.de>
References: <d17b77a40906170910h607175bcm6d51a23e0e11db6c@mail.gmail.com>
	<4A391DCB.8070307@assumetheposition.nl>
	<24361044-96E1-4490-A7B6-31A4E097CB46@apple.com>
	<4A3942A8.2000608@t-online.de>
Message-ID: <4EC03F48-820F-490E-9BE2-8B7C313654E6@apple.com>


On Jun 17, 2009, at 12:23 PM, Albert Graef wrote:

> Chris Lattner wrote:
>> For JIT applications, please include llvm/Target/TargetSelect.h and
>> call the llvm::InitializeNativeTarget() function before creating an  
>> EE.
>
> Couldn't the EE creation functions do this call automatically if no
> target has been set yet, instead of just returning a null pointer? For
> the sake of backward compatibility.

No, the whole point of this is to make it trivial for a JIT to link in  
just the code generator it needs.  If the EE depended on all the  
targets, then all the targets would have to get linked in.  This would  
be bad for code size reasons among other things.

-Chris


From clattner at apple.com  Wed Jun 17 13:05:17 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 17 Jun 2009 13:05:17 -0700
Subject: [LLVMdev] Undocumented API changes
In-Reply-To: <4A393EC4.80205@dcs.gla.ac.uk>
References: <d17b77a40906170910h607175bcm6d51a23e0e11db6c@mail.gmail.com>
	<4A391DCB.8070307@assumetheposition.nl>
	<24361044-96E1-4490-A7B6-31A4E097CB46@apple.com>
	<4A393EC4.80205@dcs.gla.ac.uk>
Message-ID: <63CDEC2F-D4A9-4E54-8372-5345D6DAA474@apple.com>

On Jun 17, 2009, at 12:06 PM, Mark Shannon wrote:
> Why are there so many undocumented (and as I far I can see)  
> unnecessary
> API changes?

They are only seem unnecessary if you don't understand the reason they  
were made.  We don't make change for change's sake :)

> Recently there has been:
>
> 1.
> For JIT applications, please include llvm/Target/TargetSelect.h and
> call the llvm::InitializeNativeTarget() function before creating an  
> EE.

This fixes long standing linkage problems and helps us move forward  
with cmake.

> 2.
> The major CHANGE is:  the JIT will no longer be safe for executing
> threaded applications without first invoking  
> llvm_start_multithreaded().
>  Please begin to update your client applications now if this affects
> you, as I will be throwing the switch in SVN sooner rather than later.

I don't believe that this is true anymore.  However, the reason for  
this series of changes is to make LLVM multithread safe, so that you  
can have multiple threads JIT'ing at the same time etc.

> 3.
> The change you should make: every call to addPassesToEmitFile,
> addPassesToEmitFileFinish, addPassesToEmitMachineCode, or
> addCommonCodeGenPasses should pass an optimization level enum rather
> than true / false for "Fast". The enum is in
> llvm/Target/TargetMachine.h:

This was made to give more control over optimization level.

> 4.
> The LLVM IR opcodes Add, Sub, and Mul have been each split into two.
> Add, Sub, and Mul now only handle integer types, and three new  
> opcodes,
> FAdd, FSub, and FMul now handle floating-point types.

This is to allow LLVM IR to more accurately model integer overflow,  
which is very important for loop optimization (particularly on 64-bit  
platforms).

> And that's just in a few days!

LLVM moves quickly :)

> I spent a lot of time and effort, getting things to work, first with
> 2.4, then with 2.5 (The changes in the API between 2.4 and 2.5 were  
> more
> than I would have liked, but mainly renaming and caught by the  
> compiler).
>
> Remember, its not just gcc-llvm and clang that use llvm.
>
> So please treat the API with respect.
> Don't change it often, and document EACH and EVERY change.

You'll notice that llvmdev was notified about all of these changes.

> Change (1) above seems to be pointless.
> Why can't the code to create the EE, just call
> llvm::InitializeNativeTarget()?

Because InitializeNativeTarget() is actually more about linking than  
initializing.  You'll notice that all the targets have empty  
implementations of this method.  However, if you don't call this, the  
(e.g.) X86 backend won't get linked into your app.

I'm sorry about API changes, but change is an inherent part of making  
LLVM better.  We will aim to document them in the 2.6 release notes.

-Chris


From resistor at mac.com  Wed Jun 17 13:15:48 2009
From: resistor at mac.com (Owen Anderson)
Date: Wed, 17 Jun 2009 13:15:48 -0700
Subject: [LLVMdev] Undocumented API changes
In-Reply-To: <4A393EC4.80205@dcs.gla.ac.uk>
References: <d17b77a40906170910h607175bcm6d51a23e0e11db6c@mail.gmail.com>
	<4A391DCB.8070307@assumetheposition.nl>
	<24361044-96E1-4490-A7B6-31A4E097CB46@apple.com>
	<4A393EC4.80205@dcs.gla.ac.uk>
Message-ID: <6D536AB2-DADD-4C0F-87FC-1E273D88A287@mac.com>


On Jun 17, 2009, at 12:06 PM, Mark Shannon wrote:
> 2.
> The major CHANGE is:  the JIT will no longer be safe for executing
> threaded applications without first invoking llvm_start_multithreaded 
> ().
>  Please begin to update your client applications now if this affects
> you, as I will be throwing the switch in SVN sooner rather than later.
>

This one is necessary for the ongoing work to make the LLVM APIs  
thread-safe.  Because of portability issues (mostly concerned with  
differences between Windows and Unix-like systems), this is the only  
acceptable way we have found to ensure that the necessary guard  
structures are allocated and available when they are needed.

> Remember, its not just gcc-llvm and clang that use llvm.
>
> So please treat the API with respect.
> Don't change it often, and document EACH and EVERY change.

I'm not sure exactly what you're getting at here.  If anything, I've  
been very impressed in the recent days with the effort people are  
putting in to announce their API-breaking changes.  It's much improved  
from the old days of no notice breakage.

The API can and will evolve over time, and we're making efforts to  
make it easier for client programs to keep up by announcing API  
changes, including recipes for how to deal with them, in an obvious  
manner in advance of the change itself.

--Owen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090617/0d6e0321/attachment.html>

From ofv at wanadoo.es  Wed Jun 17 13:24:57 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Wed, 17 Jun 2009 22:24:57 +0200
Subject: [LLVMdev] Undocumented API changes
References: <d17b77a40906170910h607175bcm6d51a23e0e11db6c@mail.gmail.com>
	<4A391DCB.8070307@assumetheposition.nl>
	<24361044-96E1-4490-A7B6-31A4E097CB46@apple.com>
	<4A393EC4.80205@dcs.gla.ac.uk>
	<63CDEC2F-D4A9-4E54-8372-5345D6DAA474@apple.com>
Message-ID: <878wjqd2w6.fsf@telefonica.net>

Chris Lattner <clattner at apple.com> writes:

>> 1.
>> For JIT applications, please include llvm/Target/TargetSelect.h and
>> call the llvm::InitializeNativeTarget() function before creating an  
>> EE.
>
> This fixes long standing linkage problems and helps us move forward  
> with cmake.

Just to clarify: the cmake build was not impeded by this issue at
all. Now we can get rid of some cmake nasty scripts, but the
implementation that managed partially linked objects was already there.

OTOH, as a LLVM user, I think it is a good thing that the partially
linked objects are gone.

[snip]

> I'm sorry about API changes, but change is an inherent part of making  
> LLVM better.  We will aim to document them in the 2.6 release notes.

Speaking as a LLVM user, API changes should be thoroughly documented on
the release notes. For instance, just dropping a one-line note
mentioning that certain API changed is not enough. The change itself
shall be described with hints for migrating the existent code, if
needed. Writing a really descriptive note does not require more than a
few minutes for the author, but it may save hours of browsing the
doxygen docs and compile-run-crash cycles to all LLVM users.

The issue about LLVM being on a constant API flux is a more complex
matter that would deserve a full thread by itself.

-- 
Óscar



From Dr.Graef at t-online.de  Wed Jun 17 13:32:44 2009
From: Dr.Graef at t-online.de (Albert Graef)
Date: Wed, 17 Jun 2009 22:32:44 +0200
Subject: [LLVMdev] Why are functions renamed for .cpp files with
	llvm-gcc?
In-Reply-To: <Pine.LNX.4.64.0906171101590.29818@melkki.cs.Helsinki.FI>
References: <Pine.LNX.4.64.0906171101590.29818@melkki.cs.Helsinki.FI>
Message-ID: <4A3952EC.40708@t-online.de>

A. Vuori wrote:
> ---bar.cpp----
> int bar() {
>     return 42;
> }
> --------------

Try extern "C" int bar() instead, then you get C binding and the name
mangling goes away.

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de
WWW:    http://www.musikinformatik.uni-mainz.de/ag


From pejic at ualberta.ca  Wed Jun 17 14:20:54 2009
From: pejic at ualberta.ca (Slobodan Pejic)
Date: Wed, 17 Jun 2009 15:20:54 -0600
Subject: [LLVMdev] Querying Path Profile Data
Message-ID: <4A395E36.5090305@ualberta.ca>

Hi,

I'm trying to get a feel for what the LLVM community wants to get out of 
path profiles.  Ball Larus path profiles contain counters for path 
numbers, but this raw information is not too useful.   Some potential 
queries follow:
- Given a path number, and function give a basic block iterator over the 
path.
- Given a function give path numbers ordered by counts.
- Given a basic block give path numbers such that the basic block is in 
each path ordered by counts.
Which queries would you like to have?

Thanks



From murat8307 at yahoo.com  Wed Jun 17 15:07:10 2009
From: murat8307 at yahoo.com (Murat B)
Date: Wed, 17 Jun 2009 15:07:10 -0700 (PDT)
Subject: [LLVMdev] Configure problem of llvm2.5 in Mac OS X 10.4.11
Message-ID: <972324.63947.qm@web63208.mail.re1.yahoo.com>

Hi,

I am trying to install llvm 2.5 in my PowerPC machine. I have already installed XCode Tools 2.4.1.
I can compile programs using gcc run them.
I try to configure llvm 2.5, the configuration aborts with following message:

checking build system type... powerpc-apple-darwin8.11.0
checking host system type... powerpc-apple-darwin8.11.0
checking target system type... powerpc-apple-darwin8.11.0
checking type of operating system we're going to host on... Darwin
checking target architecture... PowerPC
checking for gcc... gcc
checking for C compiler default output file name... configure: error: C compiler cannot create executables
See `config.log' for more details.

Does anyone know why it aborts at that point? I also copy the content of config.log below.

Thanks or your help in advance!

Sincelery,
Murat

File: config.log
===========

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by llvm configure 2.5, which was
generated by GNU Autoconf 2.60.  Invocation command line was

  $ ./configure 

## --------- ##
## Platform. ##
## --------- ##

hostname = x.local
uname -m = Power Macintosh
uname -r = 8.11.0
uname -s = Darwin
uname -v = Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC

/usr/bin/uname -p = powerpc
/bin/uname -X     = unknown

/bin/arch              = unknown
/usr/bin/arch -k       = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo      = Mach kernel version:
     Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC
Kernel configured for up to 2 processors.
2 processors are physically available.
Processor type: ppc970 (PowerPC 970)
Processors active: 0 1
Primary memory available: 4.50 gigabytes
Default processor set: 52 tasks, 173 threads, 2 processors
Load average: 0.81, Mach factor: 1.18
/bin/machine           = unknown
/usr/bin/oslevel       = unknown
/bin/universe          = unknown

PATH: /Users/bolat/bin
PATH: /opt/bin
PATH: /usr/local/bin
PATH: /usr/bin
PATH: /bin
PATH: /usr/local/sbin/
PATH: /usr/sbin
PATH: /sbin
PATH: /sw/bin
PATH: /usr/local/teTeX/bin/powerpc-apple-darwin-current
PATH: /sw/LessTif/Motif2.0/bin
PATH: /usr/X11R6/bin
PATH: /Developer/Tools


## ----------- ##
## Core tests. ##
## ----------- ##

configure:2131: checking build system type
configure:2149: result: powerpc-apple-darwin8.11.0
configure:2171: checking host system type
configure:2186: result: powerpc-apple-darwin8.11.0
configure:2208: checking target system type
configure:2223: result: powerpc-apple-darwin8.11.0
configure:2252: checking type of operating system we're going to host on
configure:2335: result: Darwin
configure:2377: checking target architecture
configure:2396: result: PowerPC
configure:2455: checking for gcc
configure:2471: found /usr/bin/gcc
configure:2482: result: gcc
configure:2720: checking for C compiler version
configure:2727: gcc --version >&5
powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5367)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:2730: $? = 0
configure:2737: gcc -v >&5
Using built-in specs.
Target: powerpc-apple-darwin8
Configured with: /private/var/tmp/gcc/gcc-5367.obj~1/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8
Thread model: posix
gcc version 4.0.1 (Apple Computer, Inc. build 5367)
configure:2740: $? = 0
configure:2747: gcc -V >&5
gcc: argument to `-V' is missing
configure:2750: $? = 1
configure:2773: checking for C compiler default output file name
configure:2800: gcc   -flat-namespace conftest.c  >&5
cc1: error: unrecognized command line option "-flat-namespace"
configure:2803: $? = 1
configure: failed program was:
| /* confdefs.h.  */
| #define PACKAGE_NAME "llvm"
| #define PACKAGE_TARNAME "-llvm-"
| #define PACKAGE_VERSION "2.5"
| #define PACKAGE_STRING "llvm 2.5"
| #define PACKAGE_BUGREPORT "llvmbugs at cs.uiuc.edu"
| #define LLVM_ON_UNIX 1
| /* end confdefs.h.  */
| 
| int
| main ()
| {
| 
|   ;
|   return 0;
| }
configure:2842: error: C compiler cannot create executables
See `config.log' for more details.

## ---------------- ##
## Cache variables. ##
## ---------------- ##

ac_cv_build=powerpc-apple-darwin8.11.0
ac_cv_env_CCC_set=
ac_cv_env_CCC_value=
ac_cv_env_CC_set=
ac_cv_env_CC_value=
ac_cv_env_CFLAGS_set=
ac_cv_env_CFLAGS_value=
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_CPP_set=
ac_cv_env_CPP_value=
ac_cv_env_CXXCPP_set=
ac_cv_env_CXXCPP_value=
ac_cv_env_CXXFLAGS_set=
ac_cv_env_CXXFLAGS_value=
ac_cv_env_CXX_set=
ac_cv_env_CXX_value=
ac_cv_env_F77_set=
ac_cv_env_F77_value=
ac_cv_env_FFLAGS_set=
ac_cv_env_FFLAGS_value=
ac_cv_env_LDFLAGS_set=set
ac_cv_env_LDFLAGS_value=-flat-namespace
ac_cv_env_YACC_set=
ac_cv_env_YACC_value=
ac_cv_env_YFLAGS_set=
ac_cv_env_YFLAGS_value=
ac_cv_env_build_alias_set=
ac_cv_env_build_alias_value=
ac_cv_env_host_alias_set=
ac_cv_env_host_alias_value=
ac_cv_env_target_alias_set=
ac_cv_env_target_alias_value=
ac_cv_host=powerpc-apple-darwin8.11.0
ac_cv_prog_ac_ct_CC=gcc
ac_cv_target=powerpc-apple-darwin8.11.0
llvm_cv_link_all_option=-Wl,-all_load
llvm_cv_no_link_all_option=-Wl,-noall_load
llvm_cv_os_type=Darwin
llvm_cv_platform_type=Unix
llvm_cv_target_arch=PowerPC

## ----------------- ##
## Output variables. ##
## ----------------- ##

ALLOCA=''
ALL_BINDINGS=''
AR=''
ARCH='PowerPC'
BINDINGS_TO_BUILD=''
BINPWD=''
BISON=''
BUILD_CC=''
BUILD_CXX=''
BUILD_EXEEXT=''
BZIP2=''
CC='gcc'
CFLAGS=''
CMP=''
CONVENIENCE_LTDL_FALSE=''
CONVENIENCE_LTDL_TRUE=''
CP=''
CPP=''
CPPFLAGS=''
CVSBUILD=''
CXX=''
CXXCPP=''
CXXFLAGS=''
DATE=''
DEBUG_RUNTIME=''
DEFS=''
DISABLE_ASSERTIONS=''
DOT=''
DOTTY=''
DOXYGEN=''
ECHO='echo'
ECHO_C=''
ECHO_N='-n'
ECHO_T=''
EGREP=''
ENABLE_CBE_PRINTF_A=''
ENABLE_DOXYGEN=''
ENABLE_EXPENSIVE_CHECKS=''
ENABLE_OPTIMIZED=''
ENABLE_PIC=''
ENABLE_THREADS=''
ENABLE_VISIBILITY_INLINES_HIDDEN=''
ENDIAN=''
EXEEXT=''
EXPENSIVE_CHECKS=''
EXTRA_OPTIONS=''
F77=''
FFLAGS=''
FIND=''
FLEX=''
GAS=''
GRAPHVIZ=''
GREP=''
GROFF=''
GV=''
GZIP=''
HAVE_PERL=''
HAVE_PTHREAD=''
HUGE_VAL_SANITY=''
INSTALL_DATA=''
INSTALL_LTDL_FALSE=''
INSTALL_LTDL_TRUE=''
INSTALL_PROGRAM=''
INSTALL_SCRIPT=''
JIT=''
LDFLAGS='-flat-namespace'
LEX=''
LEXLIB=''
LEX_OUTPUT_ROOT=''
LIBADD_DL=''
LIBOBJS=''
LIBS=''
LIBTOOL=''
LINKALL='-Wl,-all_load'
LLVMCC1=''
LLVMCC1PLUS=''
LLVMGCC=''
LLVMGCCDIR=''
LLVMGCCLIBEXEC=''
LLVMGCC_LANGS=''
LLVMGCC_MAJVERS=''
LLVMGCC_VERSION=''
LLVMGXX=''
LLVM_BINDIR=''
LLVM_CONFIGTIME=''
LLVM_COPYRIGHT='Copyright (c) 2003-2008 University of Illinois at Urbana-Champaign.'
LLVM_CROSS_COMPILING=''
LLVM_DATADIR=''
LLVM_DOCSDIR=''
LLVM_ETCDIR=''
LLVM_INCLUDEDIR=''
LLVM_INFODIR=''
LLVM_LIBDIR=''
LLVM_MANDIR=''
LLVM_ON_UNIX='1'
LLVM_ON_WIN32='0'
LLVM_PREFIX=''
LN_S=''
LTLIBOBJS=''
MKDIR=''
MMAP_FILE=''
MV=''
NM=''
NOLINKALL='-Wl,-noall_load'
OBJEXT=''
OCAMLC=''
OCAMLDEP=''
OCAMLDOC=''
OCAMLOPT=''
OCAML_LIBDIR=''
OS='Darwin'
PACKAGE_BUGREPORT='llvmbugs at cs.uiuc.edu'
PACKAGE_NAME='llvm'
PACKAGE_STRING='llvm 2.5'
PACKAGE_TARNAME='-llvm-'
PACKAGE_VERSION='2.5'
PATH_SEPARATOR=':'
PERL=''
POD2HTML=''
POD2MAN=''
RANLIB=''
RM=''
RUNTEST=''
SED=''
SHELL='/bin/sh'
SHLIBEXT=''
STRIP=''
TAR=''
TARGETS_TO_BUILD=''
TARGET_HAS_JIT=''
TCLSH=''
USE_UDIS86=''
YACC=''
YFLAGS=''
ZIP=''
ac_ct_CC='gcc'
ac_ct_CXX=''
ac_ct_F77=''
bindir='${exec_prefix}/bin'
build='powerpc-apple-darwin8.11.0'
build_alias=''
build_cpu='powerpc'
build_os='darwin8.11.0'
build_vendor='apple'
datadir='${datarootdir}'
datarootdir='${prefix}/share'
docdir='${datarootdir}/doc/${PACKAGE_TARNAME}'
dvidir='${docdir}'
exec_prefix='NONE'
host='powerpc-apple-darwin8.11.0'
host_alias=''
host_cpu='powerpc'
host_os='darwin8.11.0'
host_vendor='apple'
htmldir='${docdir}'
ifGNUmake=''
includedir='${prefix}/include'
infodir='${datarootdir}/info'
libdir='${exec_prefix}/lib'
libexecdir='${exec_prefix}/libexec'
localedir='${datarootdir}/locale'
localstatedir='${prefix}/var'
mandir='${datarootdir}/man'
oldincludedir='/usr/include'
pdfdir='${docdir}'
prefix='NONE'
program_transform_name='s,x,x,'
psdir='${docdir}'
sbindir='${exec_prefix}/sbin'
sharedstatedir='${prefix}/com'
subdirs=' projects/sample'
sysconfdir='${prefix}/etc'
target='powerpc-apple-darwin8.11.0'
target_alias=''
target_cpu='powerpc'
target_os='darwin8.11.0'
target_vendor='apple'

## ----------- ##
## confdefs.h. ##
## ----------- ##

#define PACKAGE_NAME "llvm"
#define PACKAGE_TARNAME "-llvm-"
#define PACKAGE_VERSION "2.5"
#define PACKAGE_STRING "llvm 2.5"
#define PACKAGE_BUGREPORT "llvmbugs at cs.uiuc.edu"
#define LLVM_ON_UNIX 1

configure: exit 77




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090617/51f14d9d/attachment.html>

From eric at brouhaha.com  Wed Jun 17 15:12:30 2009
From: eric at brouhaha.com (Eric Smith)
Date: Wed, 17 Jun 2009 15:12:30 -0700
Subject: [LLVMdev] making trampolines more portable
Message-ID: <4A396A4E.5030709@brouhaha.com>

Eli Friedman wrote:
 > Also, for lack of an intrinsic, there's a relatively easy workaround:
 > you can declare a global containing the correct size, then link in a
 > small target-specific .bc with the definition right before code
 > generation.

So why can't LLVM provide that global?  I don't care whether it's a 
global, intrinsic, or whatever.  If I have to provide it in my software, 
I'll have to track any changes that happen in LLVM-generated trampolines 
in the future.

My point is that LLVM is unnecessarily requiring software that generates 
LLVM bitcode to know things about the target, which defeats the purpose 
of the "V" in LLVM.

I should be able to generate a .bc file, and email it to someone, and 
they should be able to use it, all without my having any clue whatsoever 
about what target architecture they're using.

Eric



From isanbard at gmail.com  Wed Jun 17 15:26:58 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Wed, 17 Jun 2009 15:26:58 -0700
Subject: [LLVMdev] Configure problem of llvm2.5 in Mac OS X 10.4.11
In-Reply-To: <972324.63947.qm@web63208.mail.re1.yahoo.com>
References: <972324.63947.qm@web63208.mail.re1.yahoo.com>
Message-ID: <16e5fdf90906171526y1978d8d5y97edc40b478807bc@mail.gmail.com>

Hi Murat,

This looks suspicious:

  LDFLAGS='-flat-namespace'

It looks like it's already defined as an environment variable. I can't
see where '-flat-namespace' is used in the configuration files. Check
to make sure that LDFLAGS has no value during the configure. :-)

-bw

On Wed, Jun 17, 2009 at 3:07 PM, Murat B<murat8307 at yahoo.com> wrote:
> Hi,
>
> I am trying to install llvm 2.5 in my PowerPC machine. I have already
> installed XCode Tools 2.4.1.
> I can compile programs using gcc run them.
> I try to configure llvm 2.5, the configuration aborts with following
> message:
>
> checking build system type... powerpc-apple-darwin8.11.0
> checking host system type... powerpc-apple-darwin8.11.0
> checking target system type... powerpc-apple-darwin8.11.0
> checking type of operating system we're going to host on... Darwin
> checking target architecture... PowerPC
> checking for gcc... gcc
> checking for C compiler default output file name... configure: error: C
> compiler cannot create executables
> See `config.log' for more details.
>
> Does anyone know why it aborts at that point? I also copy the content of
> config.log below.
>
> Thanks or your help in advance!
>
> Sincelery,
> Murat
>
> File: config.log
> ===========
>
> This file contains any messages produced by compilers while
> running configure, to aid debugging if configure makes a mistake.
>
> It was created by llvm configure 2.5, which was
> generated by GNU Autoconf 2.60.  Invocation command line was
>
>   $ ./configure
>
> ## --------- ##
> ## Platform. ##
> ## --------- ##
>
> hostname = x.local
> uname -m = Power Macintosh
> uname -r = 8.11.0
> uname -s = Darwin
> uname -v = Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007;
> root:xnu-792.24.17~1/RELEASE_PPC
>
> /usr/bin/uname -p = powerpc
> /bin/uname -X     = unknown
>
> /bin/arch              = unknown
> /usr/bin/arch -k       = unknown
> /usr/convex/getsysinfo = unknown
> /usr/bin/hostinfo      = Mach kernel version:
>      Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007;
> root:xnu-792.24.17~1/RELEASE_PPC
> Kernel configured for up to 2 processors.
> 2 processors are physically available.
> Processor type: ppc970 (PowerPC 970)
> Processors active: 0 1
> Primary memory available: 4.50 gigabytes
> Default processor set: 52 tasks, 173 threads, 2 processors
> Load average: 0.81, Mach factor: 1.18
> /bin/machine           = unknown
> /usr/bin/oslevel       = unknown
> /bin/universe          = unknown
>
> PATH: /Users/bolat/bin
> PATH: /opt/bin
> PATH: /usr/local/bin
> PATH: /usr/bin
> PATH: /bin
> PATH: /usr/local/sbin/
> PATH: /usr/sbin
> PATH: /sbin
> PATH: /sw/bin
> PATH: /usr/local/teTeX/bin/powerpc-apple-darwin-current
> PATH: /sw/LessTif/Motif2.0/bin
> PATH: /usr/X11R6/bin
> PATH: /Developer/Tools
>
>
> ## ----------- ##
> ## Core tests. ##
> ## ----------- ##
>
> configure:2131: checking build system type
> configure:2149: result: powerpc-apple-darwin8.11.0
> configure:2171: checking host system type
> configure:2186: result: powerpc-apple-darwin8.11.0
> configure:2208: checking target system type
> configure:2223: result: powerpc-apple-darwin8.11.0
> configure:2252: checking type of operating system we're going to host on
> configure:2335: result: Darwin
> configure:2377: checking target architecture
> configure:2396: result: PowerPC
> configure:2455: checking for gcc
> configure:2471: found /usr/bin/gcc
> configure:2482: result: gcc
> configure:2720: checking for C compiler version
> configure:2727: gcc --version >&5
> powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build
> 5367)
> Copyright (C) 2005 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> configure:2730: $? = 0
> configure:2737: gcc -v >&5
> Using built-in specs.
> Target: powerpc-apple-darwin8
> Configured with: /private/var/tmp/gcc/gcc-5367.obj~1/src/configure
> --disable-checking -enable-werror --prefix=/usr --mandir=/share/man
> --enable-languages=c,objc,c++,obj-c++
> --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
> --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
> --build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8
> --target=powerpc-apple-darwin8
> Thread model: posix
> gcc version 4.0.1 (Apple Computer, Inc. build 5367)
> configure:2740: $? = 0
> configure:2747: gcc -V >&5
> gcc: argument to `-V' is missing
> configure:2750: $? = 1
> configure:2773: checking for C compiler default output file name
> configure:2800: gcc   -flat-namespace conftest.c  >&5
> cc1: error: unrecognized command line option "-flat-namespace"
> configure:2803: $? = 1
> configure: failed program was:
> | /* confdefs.h.  */
> | #define PACKAGE_NAME "llvm"
> | #define PACKAGE_TARNAME "-llvm-"
> | #define PACKAGE_VERSION "2.5"
> | #define PACKAGE_STRING "llvm 2.5"
> | #define PACKAGE_BUGREPORT "llvmbugs at cs.uiuc.edu"
> | #define LLVM_ON_UNIX 1
> | /* end confdefs.h.  */
> |
> | int
> | main ()
> | {
> |
> |   ;
> |   return 0;
> | }
> configure:2842: error: C compiler cannot create executables
> See `config.log' for more details.
>
> ## ---------------- ##
> ## Cache variables. ##
> ## ---------------- ##
>
> ac_cv_build=powerpc-apple-darwin8.11.0
> ac_cv_env_CCC_set=
> ac_cv_env_CCC_value=
> ac_cv_env_CC_set=
> ac_cv_env_CC_value=
> ac_cv_env_CFLAGS_set=
> ac_cv_env_CFLAGS_value=
> ac_cv_env_CPPFLAGS_set=
> ac_cv_env_CPPFLAGS_value=
> ac_cv_env_CPP_set=
> ac_cv_env_CPP_value=
> ac_cv_env_CXXCPP_set=
> ac_cv_env_CXXCPP_value=
> ac_cv_env_CXXFLAGS_set=
> ac_cv_env_CXXFLAGS_value=
> ac_cv_env_CXX_set=
> ac_cv_env_CXX_value=
> ac_cv_env_F77_set=
> ac_cv_env_F77_value=
> ac_cv_env_FFLAGS_set=
> ac_cv_env_FFLAGS_value=
> ac_cv_env_LDFLAGS_set=set
> ac_cv_env_LDFLAGS_value=-flat-namespace
> ac_cv_env_YACC_set=
> ac_cv_env_YACC_value=
> ac_cv_env_YFLAGS_set=
> ac_cv_env_YFLAGS_value=
> ac_cv_env_build_alias_set=
> ac_cv_env_build_alias_value=
> ac_cv_env_host_alias_set=
> ac_cv_env_host_alias_value=
> ac_cv_env_target_alias_set=
> ac_cv_env_target_alias_value=
> ac_cv_host=powerpc-apple-darwin8.11.0
> ac_cv_prog_ac_ct_CC =gcc
> ac_cv_target=powerpc-apple-darwin8.11.0
> llvm_cv_link_all_option=-Wl,-all_load
> llvm_cv_no_link_all_option=-Wl,-noall_load
> llvm_cv_os_type=Darwin
> llvm_cv_platform_type=Unix
> llvm_cv_target_arch=PowerPC
>
> ## ----------------- ##
> ## Output variables. ##
> ## ----------------- ##
>
> ALLOCA=''
> ALL_BINDINGS=''
> AR=''
> ARCH='PowerPC'
> BINDINGS_TO_BUILD=''
> BINPWD=''
> BISON=''
> BUILD_CC=''
> BUILD_CXX=''
> BUILD_EXEEXT=''
> BZIP2=''
> CC='gcc'
> CFLAGS=''
> CMP=''
> CONVENIENCE_LTDL_FALSE=''
> CONVENIENCE_LTDL_TRUE=''
> CP=''
> CPP=''
> CPPFLAGS=''
> CVSBUILD=''
> CXX=''
> CXXCPP=''
> CXXFLAGS=''
> DATE=''
> DEBUG_RUNTIME=''
> DEFS=''
> DISABLE_ASSERTIONS=''
> DOT=''
> DOTTY=''
> DOXYGEN=''
> ECHO='echo'
> ECHO_C=''
> ECHO_N='-n'
> ECHO_T=''
> EGREP=''
> ENABLE_CBE_PRINTF_A=''
> ENABLE_DOXYGEN=''
> ENABLE_EXPENSIVE_CHECKS=''
> ENABLE_OPTIMIZED=''
> ENABLE_PIC=''
> ENABLE_THREADS=''
> ENABLE_VISIBILITY_INLINES_HIDDEN=''
> ENDIAN=''
> EXEEXT=''
> EXPENSIVE_CHECKS=''
> EXTRA_OPTIONS=''
> F77=''
> FFLAGS=''
> FIND=''
> FLEX=''
> GAS=''
> GRAPHVIZ=''
> GREP=''
> GROFF=''
> GV=''
> GZIP=''
> HAVE_PERL=''
> HAVE_PTHREAD=''
> HUGE_VAL_SANITY=''
> INSTALL_DATA=''
> I NSTALL_LTDL_FALSE=''
> INSTALL_LTDL_TRUE=''
> INSTALL_PROGRAM=''
> INSTALL_SCRIPT=''
> JIT=''
> LDFLAGS='-flat-namespace'
> LEX=''
> LEXLIB=''
> LEX_OUTPUT_ROOT=''
> LIBADD_DL=''
> LIBOBJS=''
> LIBS=''
> LIBTOOL=''
> LINKALL='-Wl,-all_load'
> LLVMCC1=''
> LLVMCC1PLUS=''
> LLVMGCC=''
> LLVMGCCDIR=''
> LLVMGCCLIBEXEC=''
> LLVMGCC_LANGS=''
> LLVMGCC_MAJVERS=''
> LLVMGCC_VERSION=''
> LLVMGXX=''
> LLVM_BINDIR=''
> LLVM_CONFIGTIME=''
> LLVM_COPYRIGHT='Copyright (c) 2003-2008 University of Illinois at
> Urbana-Champaign.'
> LLVM_CROSS_COMPILING=''
> LLVM_DATADIR=''
> LLVM_DOCSDIR=''
> LLVM_ETCDIR=''
> LLVM_INCLUDEDIR=''
> LLVM_INFODIR=''
> LLVM_LIBDIR=''
> LLVM_MANDIR=''
> LLVM_ON_UNIX='1'
> LLVM_ON_WIN32='0'
> LLVM_PREFIX=''
> LN_S=''
> LTLIBOBJS=''
> MKDIR=''
> MMAP_FILE=''
> MV=''
> NM=''
> NOLINKALL='-Wl,-noall_load'
> OBJEXT=''
> OCAMLC=''
> OCAMLDEP=''
> OCAMLDOC=''
> OCAMLOPT=''
> OCAML_LIBDIR=''
> OS='Darwin'
> PACKAGE_BUGREPORT='llvmbugs at cs.uiuc.edu'
> PACKAGE_NAME='llvm'
> PACKAGE_STRING='llvm 2.5'
> PACKAGE_TARNAME='-llvm-'
> PACKAGE_VERSION='2.5'
> PATH_SEPARATOR=':'
> PERL=''
> POD2HTML=''
> POD2MAN=''
> RANLIB=''
> RM=''
> RUNTEST=''
> SED=''
> SHELL='/bin/sh'
> SHLIBEXT=''
> STRIP=''
> TAR=''
> TARGETS_TO_BUILD=''
> TARGET_HAS_JIT=''
> TCLSH=''
> USE_UDIS86=''
> YACC=''
> YFLAGS=''
> ZIP=''
> ac_ct_CC='gcc'
> ac_ct_CXX=''
> ac_ct_F77=''
> bindir='${exec_prefix}/bin'
> build='powerpc-apple-darwin8.11.0'
> build_alias=''
> build_cpu='powerpc'
> build_os='darwin8.11.0'
> build_vendor='apple'
> datadir='${datarootdir}'
> datarootdir='${prefix}/share'
> docdir='${datarootdir}/doc/${PACKAGE_TARNAME}'
> dvidir='${docdir}'
> exec_prefix='NONE'
> host='powerpc-apple-darwin8.11.0'
> host_alias=''
> host_cpu='powerpc'
> host_os='darwin8.11.0'
> host_vendor='apple'
> htmldir='${docdir}'
> ifGNUmake=''
> includedir='${prefix}/include'
> infodir='${datarootdir}/info'
> libdir='${exec_prefix}/lib'
> libexe cdir='${exec_prefix}/libexec'
> localedir='${datarootdir}/locale'
> localstatedir='${prefix}/var'
> mandir='${datarootdir}/man'
> oldincludedir='/usr/include'
> pdfdir='${docdir}'
> prefix='NONE'
> program_transform_name='s,x,x,'
> psdir='${docdir}'
> sbindir='${exec_prefix}/sbin'
> sharedstatedir='${prefix}/com'
> subdirs=' projects/sample'
> sysconfdir='${prefix}/etc'
> target='powerpc-apple-darwin8.11.0'
> target_alias=''
> target_cpu='powerpc'
> target_os='darwin8.11.0'
> target_vendor='apple'
>
> ## ----------- ##
> ## confdefs.h. ##
> ## ----------- ##
>
> #define PACKAGE_NAME "llvm"
> #define PACKAGE_TARNAME "-llvm-"
> #define PACKAGE_VERSION "2.5"
> #define PACKAGE_STRING "llvm 2.5"
> #define PACKAGE_BUGREPORT "llvmbugs at cs.uiuc.edu"
> #define LLVM_ON_UNIX 1
>
> configure: exit 77
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>



From mainmanmauricio at gmail.com  Wed Jun 17 15:35:29 2009
From: mainmanmauricio at gmail.com (Maurice Gittens)
Date: Thu, 18 Jun 2009 00:35:29 +0200
Subject: [LLVMdev] Inconsistent naming of functions?
Message-ID: <305911e30906171535m5c9e53cbh21d4dbf5d954795@mail.gmail.com>

Hi all,

maybe it is just me but I feel the function named:

        llvm::llvm_start_multithreaded();

has to one to many llvm substrings in it.

How about renaming it to:

        llvm::start_multithreaded();


This would be consistent with functions like:

        llvm::InitializeNativeTarget();

No?

Kind regards,
Maurice

PS: Now I am off to figure out why I suddenly get all these linker errors
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090618/e13dd6e5/attachment.html>

From murat8307 at yahoo.com  Wed Jun 17 17:54:38 2009
From: murat8307 at yahoo.com (Murat B)
Date: Wed, 17 Jun 2009 17:54:38 -0700 (PDT)
Subject: [LLVMdev] Configure problem of llvm2.5 in Mac OS X 10.4.11
Message-ID: <761234.40786.qm@web63207.mail.re1.yahoo.com>

I can configure it now. Thank You!

--- On Wed, 6/17/09, Bill Wendling <isanbard at gmail.com> wrote:

From: Bill Wendling <isanbard at gmail.com>
Subject: Re: [LLVMdev] Configure problem of llvm2.5 in Mac OS X 10.4.11
To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
Date: Wednesday, June 17, 2009, 6:26 PM

Hi Murat,

This looks suspicious:

  LDFLAGS='-flat-namespace'

It looks like it's already defined as an environment variable. I can't
see where '-flat-namespace' is used in the configuration files. Check
to make sure that LDFLAGS has no value during the configure. :-)

-bw

On Wed, Jun 17, 2009 at 3:07 PM, Murat B<murat8307 at yahoo.com> wrote:
> Hi,
>
> I am trying to install llvm 2.5 in my PowerPC machine. I have already
> installed XCode Tools 2.4.1.
> I can compile programs using gcc run them.
> I try to configure llvm 2.5, the configuration aborts with following
> message:
>
> checking build system type... powerpc-apple-darwin8.11.0
> checking host system type... powerpc-apple-darwin8.11.0
> checking target system type... powerpc-apple-darwin8.11.0
> checking type of operating system we're going to host on... Darwin
> checking target architecture... PowerPC
> checking for gcc... gcc
> checking for C compiler default output file name... configure: error: C
> compiler cannot create executables
> See `config.log' for more details.
>
> Does anyone know why it aborts at that point? I also copy the content of
> config.log below.
>
> Thanks or your help in advance!
>
> Sincelery,
> Murat
>
> File: config.log
> ===========
>
> This file contains any messages produced by compilers while
> running configure, to aid debugging if configure makes a mistake.
>
> It was created by llvm configure 2.5, which was
> generated by GNU Autoconf 2.60.  Invocation command line was
>
>   $ ./configure
>
> ## --------- ##
> ## Platform. ##
> ## --------- ##
>
> hostname = x.local
> uname -m = Power Macintosh
> uname -r = 8.11.0
> uname -s = Darwin
> uname -v = Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007;
> root:xnu-792.24.17~1/RELEASE_PPC
>
> /usr/bin/uname -p = powerpc
> /bin/uname -X     = unknown
>
> /bin/arch              = unknown
> /usr/bin/arch -k       = unknown
> /usr/convex/getsysinfo = unknown
> /usr/bin/hostinfo      = Mach kernel version:
>      Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007;
> root:xnu-792.24.17~1/RELEASE_PPC
> Kernel configured for up to 2 processors.
> 2 processors are physically available.
> Processor type: ppc970 (PowerPC 970)
> Processors active: 0 1
> Primary memory available: 4.50 gigabytes
> Default processor set: 52 tasks, 173 threads, 2 processors
> Load average: 0.81, Mach factor: 1.18
> /bin/machine           = unknown
> /usr/bin/oslevel       = unknown
> /bin/universe          = unknown
>
> PATH: /Users/bolat/bin
> PATH: /opt/bin
> PATH: /usr/local/bin
> PATH: /usr/bin
> PATH: /bin
> PATH: /usr/local/sbin/
> PATH: /usr/sbin
> PATH: /sbin
> PATH: /sw/bin
> PATH: /usr/local/teTeX/bin/powerpc-apple-darwin-current
> PATH: /sw/LessTif/Motif2.0/bin
> PATH: /usr/X11R6/bin
> PATH: /Developer/Tools
>
>
> ## ----------- ##
> ## Core tests. ##
> ## ----------- ##
>
> configure:2131: checking build system type
> configure:2149: result: powerpc-apple-darwin8.11.0
> configure:2171: checking host system type
> configure:2186: result: powerpc-apple-darwin8.11.0
> configure:2208: checking target system type
> configure:2223: result: powerpc-apple-darwin8.11.0
> configure:2252: checking type of operating system we're going to host on
> configure:2335: result: Darwin
> configure:2377: checking target architecture
> configure:2396: result: PowerPC
> configure:2455: checking for gcc
> configure:2471: found /usr/bin/gcc
> configure:2482: result: gcc
> configure:2720: checking for C compiler version
> configure:2727: gcc --version >&5
> powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build
> 5367)
> Copyright (C) 2005 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> configure:2730: $? = 0
> configure:2737: gcc -v >&5
> Using built-in specs.
> Target: powerpc-apple-darwin8
> Configured with: /private/var/tmp/gcc/gcc-5367.obj~1/src/configure
> --disable-checking -enable-werror --prefix=/usr --mandir=/share/man
> --enable-languages=c,objc,c++,obj-c++
> --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
> --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
> --build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8
> --target=powerpc-apple-darwin8
> Thread model: posix
> gcc version 4.0.1 (Apple Computer, Inc. build 5367)
> configure:2740: $? = 0
> configure:2747: gcc -V >&5
> gcc: argument to `-V' is missing
> configure:2750: $? = 1
> configure:2773: checking for C compiler default output file name
> configure:2800: gcc   -flat-namespace conftest.c  >&5
> cc1: error: unrecognized command line option "-flat-namespace"
> configure:2803: $? = 1
> configure: failed program was:
> | /* confdefs.h.  */
> | #define PACKAGE_NAME "llvm"
> | #define PACKAGE_TARNAME "-llvm-"
> | #define PACKAGE_VERSION "2.5"
> | #define PACKAGE_STRING "llvm 2.5"
> | #define PACKAGE_BUGREPORT "llvmbugs at cs.uiuc.edu"
> | #define LLVM_ON_UNIX 1
> | /* end confdefs.h.  */
> |
> | int
> | main ()
> | {
> |
> |   ;
> |   return 0;
> | }
> configure:2842: error: C compiler cannot create executables
> See `config.log' for more details.
>
> ## ---------------- ##
> ## Cache variables. ##
> ## ---------------- ##
>
> ac_cv_build=powerpc-apple-darwin8.11.0
> ac_cv_env_CCC_set=
> ac_cv_env_CCC_value=
> ac_cv_env_CC_set=
> ac_cv_env_CC_value=
> ac_cv_env_CFLAGS_set=
> ac_cv_env_CFLAGS_value=
> ac_cv_env_CPPFLAGS_set=
> ac_cv_env_CPPFLAGS_value=
> ac_cv_env_CPP_set=
> ac_cv_env_CPP_value=
> ac_cv_env_CXXCPP_set=
> ac_cv_env_CXXCPP_value=
> ac_cv_env_CXXFLAGS_set=
> ac_cv_env_CXXFLAGS_value=
> ac_cv_env_CXX_set=
> ac_cv_env_CXX_value=
> ac_cv_env_F77_set=
> ac_cv_env_F77_value=
> ac_cv_env_FFLAGS_set=
> ac_cv_env_FFLAGS_value=
> ac_cv_env_LDFLAGS_set=set
> ac_cv_env_LDFLAGS_value=-flat-namespace
> ac_cv_env_YACC_set=
> ac_cv_env_YACC_value=
> ac_cv_env_YFLAGS_set=
> ac_cv_env_YFLAGS_value=
> ac_cv_env_build_alias_set=
> ac_cv_env_build_alias_value=
> ac_cv_env_host_alias_set=
> ac_cv_env_host_alias_value=
> ac_cv_env_target_alias_set=
> ac_cv_env_target_alias_value=
> ac_cv_host=powerpc-apple-darwin8.11.0
> ac_cv_prog_ac_ct_CC =gcc
> ac_cv_target=powerpc-apple-darwin8.11.0
> llvm_cv_link_all_option=-Wl,-all_load
> llvm_cv_no_link_all_option=-Wl,-noall_load
> llvm_cv_os_type=Darwin
> llvm_cv_platform_type=Unix
> llvm_cv_target_arch=PowerPC
>
> ## ----------------- ##
> ## Output variables. ##
> ## ----------------- ##
>
> ALLOCA=''
> ALL_BINDINGS=''
> AR=''
> ARCH='PowerPC'
> BINDINGS_TO_BUILD=''
> BINPWD=''
> BISON=''
> BUILD_CC=''
> BUILD_CXX=''
> BUILD_EXEEXT=''
> BZIP2=''
> CC='gcc'
> CFLAGS=''
> CMP=''
> CONVENIENCE_LTDL_FALSE=''
> CONVENIENCE_LTDL_TRUE=''
> CP=''
> CPP=''
> CPPFLAGS=''
> CVSBUILD=''
> CXX=''
> CXXCPP=''
> CXXFLAGS=''
> DATE=''
> DEBUG_RUNTIME=''
> DEFS=''
> DISABLE_ASSERTIONS=''
> DOT=''
> DOTTY=''
> DOXYGEN=''
> ECHO='echo'
> ECHO_C=''
> ECHO_N='-n'
> ECHO_T=''
> EGREP=''
> ENABLE_CBE_PRINTF_A=''
> ENABLE_DOXYGEN=''
> ENABLE_EXPENSIVE_CHECKS=''
> ENABLE_OPTIMIZED=''
> ENABLE_PIC=''
> ENABLE_THREADS=''
> ENABLE_VISIBILITY_INLINES_HIDDEN=''
> ENDIAN=''
> EXEEXT=''
> EXPENSIVE_CHECKS=''
> EXTRA_OPTIONS=''
> F77=''
> FFLAGS=''
> FIND=''
> FLEX=''
> GAS=''
> GRAPHVIZ=''
> GREP=''
> GROFF=''
> GV=''
> GZIP=''
> HAVE_PERL=''
> HAVE_PTHREAD=''
> HUGE_VAL_SANITY=''
> INSTALL_DATA=''
> I NSTALL_LTDL_FALSE=''
> INSTALL_LTDL_TRUE=''
> INSTALL_PROGRAM=''
> INSTALL_SCRIPT=''
> JIT=''
> LDFLAGS='-flat-namespace'
> LEX=''
> LEXLIB=''
> LEX_OUTPUT_ROOT=''
> LIBADD_DL=''
> LIBOBJS=''
> LIBS=''
> LIBTOOL=''
> LINKALL='-Wl,-all_load'
> LLVMCC1=''
> LLVMCC1PLUS=''
> LLVMGCC=''
> LLVMGCCDIR=''
> LLVMGCCLIBEXEC=''
> LLVMGCC_LANGS=''
> LLVMGCC_MAJVERS=''
> LLVMGCC_VERSION=''
> LLVMGXX=''
> LLVM_BINDIR=''
> LLVM_CONFIGTIME=''
> LLVM_COPYRIGHT='Copyright (c) 2003-2008 University of Illinois at
> Urbana-Champaign.'
> LLVM_CROSS_COMPILING=''
> LLVM_DATADIR=''
> LLVM_DOCSDIR=''
> LLVM_ETCDIR=''
> LLVM_INCLUDEDIR=''
> LLVM_INFODIR=''
> LLVM_LIBDIR=''
> LLVM_MANDIR=''
> LLVM_ON_UNIX='1'
> LLVM_ON_WIN32='0'
> LLVM_PREFIX=''
> LN_S=''
> LTLIBOBJS=''
> MKDIR=''
> MMAP_FILE=''
> MV=''
> NM=''
> NOLINKALL='-Wl,-noall_load'
> OBJEXT=''
> OCAMLC=''
> OCAMLDEP=''
> OCAMLDOC=''
> OCAMLOPT=''
> OCAML_LIBDIR=''
> OS='Darwin'
> PACKAGE_BUGREPORT='llvmbugs at cs.uiuc.edu'
> PACKAGE_NAME='llvm'
> PACKAGE_STRING='llvm 2.5'
> PACKAGE_TARNAME='-llvm-'
> PACKAGE_VERSION='2.5'
> PATH_SEPARATOR=':'
> PERL=''
> POD2HTML=''
> POD2MAN=''
> RANLIB=''
> RM=''
> RUNTEST=''
> SED=''
> SHELL='/bin/sh'
> SHLIBEXT=''
> STRIP=''
> TAR=''
> TARGETS_TO_BUILD=''
> TARGET_HAS_JIT=''
> TCLSH=''
> USE_UDIS86=''
> YACC=''
> YFLAGS=''
> ZIP=''
> ac_ct_CC='gcc'
> ac_ct_CXX=''
> ac_ct_F77=''
> bindir='${exec_prefix}/bin'
> build='powerpc-apple-darwin8.11.0'
> build_alias=''
> build_cpu='powerpc'
> build_os='darwin8.11.0'
> build_vendor='apple'
> datadir='${datarootdir}'
> datarootdir='${prefix}/share'
> docdir='${datarootdir}/doc/${PACKAGE_TARNAME}'
> dvidir='${docdir}'
> exec_prefix='NONE'
> host='powerpc-apple-darwin8.11.0'
> host_alias=''
> host_cpu='powerpc'
> host_os='darwin8.11.0'
> host_vendor='apple'
> htmldir='${docdir}'
> ifGNUmake=''
> includedir='${prefix}/include'
> infodir='${datarootdir}/info'
> libdir='${exec_prefix}/lib'
> libexe cdir='${exec_prefix}/libexec'
> localedir='${datarootdir}/locale'
> localstatedir='${prefix}/var'
> mandir='${datarootdir}/man'
> oldincludedir='/usr/include'
> pdfdir='${docdir}'
> prefix='NONE'
> program_transform_name='s,x,x,'
> psdir='${docdir}'
> sbindir='${exec_prefix}/sbin'
> sharedstatedir='${prefix}/com'
> subdirs=' projects/sample'
> sysconfdir='${prefix}/etc'
> target='powerpc-apple-darwin8.11.0'
> target_alias=''
> target_cpu='powerpc'
> target_os='darwin8.11.0'
> target_vendor='apple'
>
> ## ----------- ##
> ## confdefs.h. ##
> ## ----------- ##
>
> #define PACKAGE_NAME "llvm"
> #define PACKAGE_TARNAME "-llvm-"
> #define PACKAGE_VERSION "2.5"
> #define PACKAGE_STRING "llvm 2.5"
> #define PACKAGE_BUGREPORT "llvmbugs at cs.uiuc.edu"
> #define LLVM_ON_UNIX 1
>
> configure: exit 77
>
>
>
> _______________________________________________
> 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.llvm.org/pipermail/llvm-dev/attachments/20090617/ab1c4b56/attachment.html>

From mcquillan.sean at gmail.com  Wed Jun 17 18:11:33 2009
From: mcquillan.sean at gmail.com (Sean McQuillan)
Date: Wed, 17 Jun 2009 18:11:33 -0700
Subject: [LLVMdev] User question,
	using IRBuilder to generate a llvm.memcpy instruction.
Message-ID: <a42b11c20906171811m1553d041w4e6fb950c6081f1a@mail.gmail.com>

Hello,

If this is not the correct list to ask this question on I apologize.

I am attempting to generate a llvm.memcpy instruction with an IRBuilder but
I cannot find the appropriate way to do this.

Thanks in advance,
Sean

--
Sean (Fritz) McQuillan - http://sean-mcquillan.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090617/d52bbce6/attachment.html>

From jyasskin at google.com  Wed Jun 17 18:34:16 2009
From: jyasskin at google.com (Jeffrey Yasskin)
Date: Wed, 17 Jun 2009 18:34:16 -0700
Subject: [LLVMdev] User question,
	using IRBuilder to generate a 	llvm.memcpy instruction.
In-Reply-To: <a42b11c20906171811m1553d041w4e6fb950c6081f1a@mail.gmail.com>
References: <a42b11c20906171811m1553d041w4e6fb950c6081f1a@mail.gmail.com>
Message-ID: <bb55930e0906171834t7557c286k627ac8a829d25912@mail.gmail.com>

http://code.google.com/p/unladen-swallow/source/browse/trunk/Python/llvm_fbuilder.cc#733
has an example of creating a memcpy call. For non-Python code, you'll
want to cast the arguments to "TypeBuilder<llvm::types::i<8>*,
true>::get()" instead.

On Wed, Jun 17, 2009 at 6:11 PM, Sean McQuillan<mcquillan.sean at gmail.com> wrote:
> Hello,
> If this is not the correct list to ask this question on I apologize.
> I am attempting to generate a llvm.memcpy instruction with an IRBuilder but
> I cannot find the appropriate way to do this.
> Thanks in advance,
> Sean
> --
> Sean (Fritz) McQuillan - http://sean-mcquillan.com/



From eli.friedman at gmail.com  Wed Jun 17 19:34:53 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Wed, 17 Jun 2009 19:34:53 -0700
Subject: [LLVMdev] making trampolines more portable
In-Reply-To: <4A396A4E.5030709@brouhaha.com>
References: <4A396A4E.5030709@brouhaha.com>
Message-ID: <f5aa3e9b0906171934q299fafc9kb63dd61755168d1f@mail.gmail.com>

On Wed, Jun 17, 2009 at 3:12 PM, Eric Smith<eric at brouhaha.com> wrote:
> Eli Friedman wrote:
>  > Also, for lack of an intrinsic, there's a relatively easy workaround:
>  > you can declare a global containing the correct size, then link in a
>  > small target-specific .bc with the definition right before code
>  > generation.
>
> So why can't LLVM provide that global?  I don't care whether it's a
> global, intrinsic, or whatever.

I didn't say we wouldn't accept a patch.  It's just that up until now
nobody has particularly cared because trampolines aren't used very
much.

-Eli



From jon at ffconsultancy.com  Thu Jun 18 00:16:37 2009
From: jon at ffconsultancy.com (Jon Harrop)
Date: Thu, 18 Jun 2009 08:16:37 +0100
Subject: [LLVMdev] ML types in LLVM
In-Reply-To: <863413A9B69F4C6584908938A3D2F2B9@HPLAPTOP>
References: <162de7480906130354m430f9e17ndbf03b41592ab982@mail.gmail.com>
	<200906160658.42914.jon@ffconsultancy.com>
	<863413A9B69F4C6584908938A3D2F2B9@HPLAPTOP>
Message-ID: <200906180816.37392.jon@ffconsultancy.com>

On Tuesday 16 June 2009 15:44:04 Aaron Gray wrote:
> Jon Harrop wrote:
> >Even if this puts LLVM at an unfair disadvantage, I think you will find
> >that
> >LLVM will thrash MLton's current x86 backend anyway.
> >
> >I did some benchmarking on HLVM and found that it was often several times
> >faster than OCaml when the GC is not the bottleneck:
> >
> >http://flyingfrogblog.blogspot.com/2009/03/performance-ocaml-vs-hlvm-beta-
> >04.html
>
> For numerical tasks and Array tasks but your graphs show for data
> manipulation for Lists LLVM is slower. I thnk you need further benchmarks,
> is this at all posible for you to do :)

The only benchmarks where HLVM does not thrash OCaml are GC intensive and that 
is solely because HLVM has a very naive and inefficient GC implementation 
(going via a hash table!). I assume Wesley intends to reuse MLton's existing 
GC which does not have these issues so I do not believe those results are 
relevant here. My point is simply that LLVM makes it easy to generate 
extremely performant x86 (and x64) code, IME.

However, I would very much like to continue benchmarking and improving HLVM. 
HLVM is currently on hold temporarily while we ship a new product but I'll 
get back to it ASAP. I would also very much like to implement a concurrent GC 
so Talin's recent news about Scarcity was very interesting to me.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e


From jon at ffconsultancy.com  Thu Jun 18 00:27:54 2009
From: jon at ffconsultancy.com (Jon Harrop)
Date: Thu, 18 Jun 2009 08:27:54 +0100
Subject: [LLVMdev] Garbage Collection Project
In-Reply-To: <4A373DAC.9060807@gmail.com>
References: <4A373DAC.9060807@gmail.com>
Message-ID: <200906180827.54686.jon@ffconsultancy.com>

On Tuesday 16 June 2009 07:37:32 Talin wrote:
> A while back there was a discussion thread about whether an accurate,
> concurrent garbage collector could be "generic" in the sense of being
> able to support multiple different languages efficiently. After having
> done some work on this, I now believe that this is the case - using C++
> policy-based design principles, you can create a set of modules that
> represent different aspects of collector behavior (such as
> mark-and-sweep, stop-the-world, and so on) along with different aspects
> of the runtime environment (object tracing strategies, heap structures,
> threading primitives, atomics), and encode these various behaviors as
> template classes which can be bound together to create an efficient
> collector.

Hi Talin,

This is great news! I have some questions...

I had great success using some seemingly-unusual techniques in my experiments.

Firstly, rather than using a single 1 word pointer to represent a reference I 
chose to use 3 words including a pointer to the type and a pointer to the 
value (as well as metadata). This allows typed nulls and that addresses an 
important deficiency found in most other VMs including the CLR. Is Scarcity 
able to handle such references or does its implementation of stack frames 
require references to be a single word?

Secondly, I used LLVM to JIT compile per-type code for garbage collection in 
order to traverse data structures as efficiently as possible. Moreover, I 
chose to write the entire GC in an unsafe subset of the language that I was 
implementing so that I could rely upon tail calls and so forth. Does Scarcity 
require the GC code to be written entirely in C?

Finally, do you have any references describing the techniques you have used to 
implement a concurrent GC? I have been reading up on the subject for several 
years now, with a view to implementing my own concurrent GC.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e


From jon at ffconsultancy.com  Thu Jun 18 00:46:38 2009
From: jon at ffconsultancy.com (Jon Harrop)
Date: Thu, 18 Jun 2009 08:46:38 +0100
Subject: [LLVMdev] ML types in LLVM
In-Reply-To: <200906180816.37392.jon@ffconsultancy.com>
References: <162de7480906130354m430f9e17ndbf03b41592ab982@mail.gmail.com>
	<863413A9B69F4C6584908938A3D2F2B9@HPLAPTOP>
	<200906180816.37392.jon@ffconsultancy.com>
Message-ID: <200906180846.39011.jon@ffconsultancy.com>

On Thursday 18 June 2009 08:16:37 Jon Harrop wrote:
> On Tuesday 16 June 2009 15:44:04 Aaron Gray wrote:
> > Jon Harrop wrote:
> > >Even if this puts LLVM at an unfair disadvantage, I think you will find
> > >that
> > >LLVM will thrash MLton's current x86 backend anyway.
> > >
> > >I did some benchmarking on HLVM and found that it was often several
> > > times faster than OCaml when the GC is not the bottleneck:
> > >
> > >http://flyingfrogblog.blogspot.com/2009/03/performance-ocaml-vs-hlvm-bet
> > >a- 04.html
> >
> > For numerical tasks and Array tasks but your graphs show for data
> > manipulation for Lists LLVM is slower. I thnk you need further
> > benchmarks, is this at all posible for you to do :)
>
> The only benchmarks where HLVM does not thrash OCaml are GC intensive and
> that is solely because HLVM has a very naive and inefficient GC
> implementation (going via a hash table!).

Incidentally, Henderson described his shadow stack algorithm as a means of 
implementing accurate garbage collection in an uncooperative environment back 
in 2002:

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.19.5570

I used a similar approach in HLVM in order to implement an accurate GC without 
having to do any unsafe low-level LLVM hacking in C++. The difference is that 
Henderson stored structs of references on the stack in order to keep them 
contiguous and pushed only a single pointer to the whole struct onto the 
shadow stack. In contrast, I literally stored every reference separately on 
the shadow stack.

Many people (particularly functional programmers, who are always whining ;-) 
have expressed concerns about using shadow stacks as a workaround for 
low-level LLVM hacking in order to implement an accurate GC. Consequently, I 
also did a little study of the impact of having used a shadow stack in HLVM:

http://flyingfrogblog.blogspot.com/2009/03/current-shadow-stack-overheads-in-hlvm.html

Suffice to say, I found the performance of the shadow stack to be more than 
adequate for my needs. However, I am somewhat unusual among functional 
programmers in that I am persuing the performance profile of F# rather than 
OCaml or Haskell. Specifically, I want to be able to implement numerical 
methods using the abstractions of a high-level language without sacrificing 
the predictably-good performance of Fortran and, in particular, I have no 
desire to be able to allocate lots of short-lived values in 
performance-critical code.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e


From evan.cheng at apple.com  Wed Jun 17 23:47:02 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Wed, 17 Jun 2009 23:47:02 -0700
Subject: [LLVMdev] [unladen-swallow] Re: Why does the x86-64 JIT
	emit	stubs for external calls?
In-Reply-To: <bb55930e0906111624r70e4d962kd35e301379294915@mail.gmail.com>
References: <bb55930e0906101217v57086e51m25829e61c22e6c7d@mail.gmail.com>
	<35A0A609-B73D-441E-88B8-E7B7B0922B81@apple.com>
	<bb55930e0906111624r70e4d962kd35e301379294915@mail.gmail.com>
Message-ID: <3403B5EB-4C57-47CA-B09E-7E52D0A1138C@apple.com>


On Jun 11, 2009, at 4:24 PM, Jeffrey Yasskin wrote:

> On Thu, Jun 11, 2009 at 12:54 PM, Evan Cheng<evan.cheng at apple.com>  
> wrote:
>>
>>
>>
>> On Jun 10, 2009, at 12:17 PM, Jeffrey Yasskin wrote:
>>
>>> In X86CodeGen.cpp, the following code appears in the handler used  
>>> for
>>> CALL64pcrel32 instructions:
>>>
>>>       // Assume undefined functions may be outside the Small  
>>> codespace.
>>>       bool NeedStub =
>>>         (Is64BitMode &&
>>>             (TM.getCodeModel() == CodeModel::Large ||
>>>              TM.getSubtarget<X86Subtarget>().isTargetDarwin())) ||
>>>         Opcode == X86::TAILJMPd;
>>>       emitGlobalAddress(MO.getGlobal(), X86::reloc_pcrel_word,
>>>                         MO.getOffset(), 0, NeedStub);
>>>
>>> This causes every external call to be emitted as a call to a stub
>>> which then jumps to the real function.
>>> I understand, thanks to the helpful folks on #llvm, that calls  
>>> across
>>> more than 31 bits of address space need to be emitted as a "mov
>>> $ADDRESS, r10; call *r10" pair instead of the simple "call
>>> rip+ADDRESS" used for calls within 31 bits. But why isn't the mov 
>>> +call
>>> pair emitted inline? And why are Darwin and TAILJMPs special?
>>
>> This is needed because of lazy compilation, before the callee is  
>> resolved,
>> it is just a JIT stub.
>
> Even with lazy compilation, the contents of the stub get emitted (by
> JITEmitter::getPointerToGlobal) as a direct call to the function, not
> the compilation callback, because the function is an external
> declaration. You can watch this happen with the following program:

There are probably some opportunities to improve upon the codegen  
here. Please file a bugzilla report, so I'd be reminded to take a look  
at some point.

>
>
> declare i32 @rand()
>
> define i32 @main() nounwind {
> entry:
> 	%call = tail call i32 @rand()		; <i32> [#uses=1]
> 	%add = add i32 %call, 2		; <i32> [#uses=1]
> 	ret i32 %add
> }
>
> and the command line `lli -debug-only=jit -march=x86-64 test.bc`.
>
> With lazy compilation and a call to an internal function, the
> JITEmitter can emit a stub even if MachineRelocation::doesntNeedStub()
> (the field NeedStub gets passed into) returns true. Only returning
> false constrains the emitter.
>
>> It's heap allocated so it may not be in the lower 4G
>> even if the code size model is small. I know this is the case on  
>> Darwin
>> x86_64, I am not sure about other targets.
>
> Oh, other targets can certainly allocate code above 4G too.
> sys::AllocateRWX just uses mmap with no constraints on the returned
> address, and I've got a Linux desktop where that always produces an
> address over 4G.
>
>> I forgot why this is needed for
>> tail calls, sorry.
>>
>> In theory we can make the code generator inline mov+call, the  
>> reality is it
>> doesn't know whether it's jitting or not. Also, we really want to  
>> keep the
>> code generation the same (as much as possible) whether it's jitting  
>> or
>> compiling. One possible solution for this is to add code size model
>> specifically for JIT so code generator can generate more efficient  
>> code in
>> that configuration.
>
> For non-JIT, the code generator doesn't ever need a stub, right? The

Right.

>
> linker does it using the relocation information? It must be ignoring
> the NeedStub parameter. ... But wait, is this code generator used for
> anything besides the JIT? Compiling uses the AsmPrinter until direct

We are talking about the system linker, it doesn't use this code. The  
code generator proper doesn't know if it's generating code for static  
compilation or for jit. The code that creates stub etc. is JIT  
specific. JIT has to do a bit more work since it can't rely on  
anything else to relocate symbols.

>
> object code generation lands, and presumably they're redesigning this
> whole subsystem.
>
>
> It sounds like I'd have to fully understand the whole structure of the
> code generator to fix this, and for <=2% performance, that's not
> really worth it. I'll probably wait for the direct object code people
> to get around to it. Thanks though.

This is not a part of the direct object code path. I'll look at it at  
some point.

Evan

>
>
>>>
>>>
>>> Having this out of line seems to lose up to 2% performance on the
>>> Unladen Swallow benchmarks, so, while it's not urgent, it'd be  
>>> nice to
>>> figure out how to avoid the stubs.
>>>
>>> What kind of patch would be welcome to fix this?
>>>
>>> Thanks,
>>> Jeffrey
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>



From mdevan.foobar at gmail.com  Thu Jun 18 00:29:24 2009
From: mdevan.foobar at gmail.com (Mahadevan R)
Date: Thu, 18 Jun 2009 12:59:24 +0530
Subject: [LLVMdev] Query on optimizing away function calls.
Message-ID: <c8033d570906180029g3ba026f8rd8e01494682e79ed@mail.gmail.com>

Hi all.

Consider the following code:

------------
define void @func() {
   %a = alloca i32
   store i32 42, i32* %a
   call void @func2(i32* %a) nounwind
   ret void
}

define void @func2(i32* %a) nounwind {
   store i32 43, i32* %a
   ret void
}
------------

It is possible to optimize this to:

------------
define void @func() {
       ret void
}

define void @func2(i32* %a) nounwind {
       store i32 43, i32* %a
       ret void
}
------------

which is just what I want. However, if @func2 is implemented in an external C
library, is this not possible? Specifically, while optimizing:

------------
define void @func() {
   %a = alloca i32
   store i32 42, i32* %a
   call void @func2(i32* %a) nounwind
   ret void
}

declare void @func2(i32* %a) nounwind
------------

is there some way to specify that @func2 only modifies values accessible via %a,
so that if all those values are ultimately discarded then the call to @func2
itself can be discarded?

The "readonly" function attribute looks to be too strict for this.

Or am I missing something obvious?

Thanks In Advance,
-Mahadevan.


From baldrick at free.fr  Thu Jun 18 00:41:54 2009
From: baldrick at free.fr (Duncan Sands)
Date: Thu, 18 Jun 2009 09:41:54 +0200
Subject: [LLVMdev] making trampolines more portable
In-Reply-To: <4A396A4E.5030709@brouhaha.com>
References: <4A396A4E.5030709@brouhaha.com>
Message-ID: <4A39EFC2.8030200@free.fr>

Hi Eric,

>  > Also, for lack of an intrinsic, there's a relatively easy workaround:
>  > you can declare a global containing the correct size, then link in a
>  > small target-specific .bc with the definition right before code
>  > generation.
> 
> So why can't LLVM provide that global?  I don't care whether it's a 
> global, intrinsic, or whatever.  If I have to provide it in my software, 
> I'll have to track any changes that happen in LLVM-generated trampolines 
> in the future.

is it important for you to have portable bitcode (i.e. the trampoline
size as some kind of symbolic constant, maybe via a global or an
intrinsic) that works on all targets or would it be enough to have the
LLVM info for the target expose the trampoline size, so when generating
IR for a target X you would query the method for target X and if it
returns "12 bytes" you would output an alloca of 12 bytes.

> I should be able to generate a .bc file, and email it to someone, and 
> they should be able to use it, all without my having any clue whatsoever 
> about what target architecture they're using.

That would be nice, but right now if you want to call external functions
(for example) you need to know target details in order to generate IR 
that conforms to the target ABI.  Just pointing out that it is hard to
generate target independent bitcode that does non-trivial things.

Ciao,

Duncan.


From sanjiv.gupta at microchip.com  Thu Jun 18 00:50:47 2009
From: sanjiv.gupta at microchip.com (Sanjiv Gupta)
Date: Thu, 18 Jun 2009 13:20:47 +0530
Subject: [LLVMdev] llvmc for PIC16
In-Reply-To: <3cb898890906150730k534167dfxf59677e966477220@mail.gmail.com>
References: <4A2633E9.4070207@microchip.com>	<loom.20090604T142600-116@post.gmane.org>	<4A28C062.9060307@microchip.com>	<loom.20090607T070933-452@post.gmane.org>	<4A35EA76.7090602@microchip.com>	<3cb898890906150348l2e0d4095seb54de38f95e69f9@mail.gmail.com>	<4A3656A3.1050403@microchip.com>
	<3cb898890906150730k534167dfxf59677e966477220@mail.gmail.com>
Message-ID: <4A39F1D7.4060101@microchip.com>

Hi Mikhail,
Thanks for your wonderful help so far. I have few more questions to ask:

How do I modify the driver to pick tools from where the driver itself 
resides, rather than from the PATH?
And how to make sure that we have same behavior on Windows as far as 
paths (/ Vs \) and  picking up tools from the driver directory is concerned?
Do I need to write some C++ code to customize such behaviors?

Thanks,
Sanjiv

Mikhail Glushenkov wrote:
> Hi Sanjiv,
>
> 2009/6/15 Sanjiv Gupta <sanjiv.gupta at microchip.com>:
>   
>> I configure llvm into a separate directory from source.
>> When I do the steps you mentioned in the source directory, this is what I
>> get.
>>     
>
> In that case, copy $LLVM_DIR/tools/llvmc/example/mcc16/Makefile to
> $LLVM_OBJ_DIR/tools/llvmc/example/mcc16/Makefile and build from that
> directory.
> _______________________________________________
> 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  Thu Jun 18 01:58:47 2009
From: baldrick at free.fr (Duncan Sands)
Date: Thu, 18 Jun 2009 10:58:47 +0200
Subject: [LLVMdev] Query on optimizing away function calls.
In-Reply-To: <c8033d570906180029g3ba026f8rd8e01494682e79ed@mail.gmail.com>
References: <c8033d570906180029g3ba026f8rd8e01494682e79ed@mail.gmail.com>
Message-ID: <4A3A01C7.8020707@free.fr>

Hi,

> Consider the following code:
> 
> ------------
> define void @func() {
>    %a = alloca i32
>    store i32 42, i32* %a
>    call void @func2(i32* %a) nounwind
>    ret void
> }
> 
> define void @func2(i32* %a) nounwind {
>    store i32 43, i32* %a
>    ret void
> }
> ------------
> 
> It is possible to optimize this to:
> 
> ------------
> define void @func() {
>        ret void
> }
> 
> define void @func2(i32* %a) nounwind {
>        store i32 43, i32* %a
>        ret void
> }
> ------------
> 
> which is just what I want. However, if @func2 is implemented in an external C
> library, is this not possible? Specifically, while optimizing:
> 
> ------------
> define void @func() {
>    %a = alloca i32
>    store i32 42, i32* %a
>    call void @func2(i32* %a) nounwind
>    ret void
> }
> 
> declare void @func2(i32* %a) nounwind
> ------------
> 
> is there some way to specify that @func2 only modifies values accessible via %a,
> so that if all those values are ultimately discarded then the call to @func2
> itself can be discarded?

no, there is currently no way.  There was some discussion of adding
attributes for this, but I think the conclusion was that there were
too many hairy details for not enough gain.

> The "readonly" function attribute looks to be too strict for this.

It is possible to put "readonly" on the call, rather than on func2
itself.  So if your front-end somehow knows that this use of func2
has no real effect it could mark the call this way.

> Or am I missing something obvious?

Nope.

Ciao,

Duncan.


From fvbommel at wxs.nl  Thu Jun 18 02:49:32 2009
From: fvbommel at wxs.nl (Frits van Bommel)
Date: Thu, 18 Jun 2009 11:49:32 +0200
Subject: [LLVMdev] Query on optimizing away function calls.
In-Reply-To: <4A3A01C7.8020707@free.fr>
References: <c8033d570906180029g3ba026f8rd8e01494682e79ed@mail.gmail.com>
	<4A3A01C7.8020707@free.fr>
Message-ID: <4A3A0DAC.70005@wxs.nl>

Duncan Sands wrote:
>> The "readonly" function attribute looks to be too strict for this.
> 
> It is possible to put "readonly" on the call, rather than on func2
> itself.  So if your front-end somehow knows that this use of func2
> has no real effect it could mark the call this way.

Unfortunately, it can only know that if it knows that %a won't be read from 
after the call...


From granvillebarnett at googlemail.com  Thu Jun 18 03:14:35 2009
From: granvillebarnett at googlemail.com (Granville Barnett)
Date: Thu, 18 Jun 2009 11:14:35 +0100
Subject: [LLVMdev] Garbage Collection Project
In-Reply-To: <200906180827.54686.jon@ffconsultancy.com>
References: <4A373DAC.9060807@gmail.com>
	<200906180827.54686.jon@ffconsultancy.com>
Message-ID: <80a70730906180314g3dc74350hf16d31bd5852c70f@mail.gmail.com>

> Firstly, rather than using a single 1 word pointer to represent a reference
> I
> chose to use 3 words including a pointer to the type and a pointer to the
> value (as well as metadata). This allows typed nulls and that addresses an
> important deficiency found in most other VMs including the CLR. Is Scarcity
> able to handle such references or does its implementation of stack frames
> require references to be a single word?
>

Three words sounds pretty expensive to me, I can see the use of an extra
word for typed nulls. If you look at something like the CLR you will see
that you have very fast access to an objects type, after all when you have a
reference to an object what you really have is a reference to an objects'
object header. From there you can access an objects syncblock (if it has
one, which is before the obj header) and the objects' method table which
includes the relevant pointers to the objects' type among other things. It
simply means you do a few hops, each of which is a constant operation
anyway.

Maybe I'm missing something key about the language you are implementing the
GC for, also is it really necessary to use an extra word for null types?

Granville

2009/6/18 Jon Harrop <jon at ffconsultancy.com>

> On Tuesday 16 June 2009 07:37:32 Talin wrote:
> > A while back there was a discussion thread about whether an accurate,
> > concurrent garbage collector could be "generic" in the sense of being
> > able to support multiple different languages efficiently. After having
> > done some work on this, I now believe that this is the case - using C++
> > policy-based design principles, you can create a set of modules that
> > represent different aspects of collector behavior (such as
> > mark-and-sweep, stop-the-world, and so on) along with different aspects
> > of the runtime environment (object tracing strategies, heap structures,
> > threading primitives, atomics), and encode these various behaviors as
> > template classes which can be bound together to create an efficient
> > collector.
>
> Hi Talin,
>
> This is great news! I have some questions...
>
> I had great success using some seemingly-unusual techniques in my
> experiments.
>
> Firstly, rather than using a single 1 word pointer to represent a reference
> I
> chose to use 3 words including a pointer to the type and a pointer to the
> value (as well as metadata). This allows typed nulls and that addresses an
> important deficiency found in most other VMs including the CLR. Is Scarcity
> able to handle such references or does its implementation of stack frames
> require references to be a single word?
>
> Secondly, I used LLVM to JIT compile per-type code for garbage collection
> in
> order to traverse data structures as efficiently as possible. Moreover, I
> chose to write the entire GC in an unsafe subset of the language that I was
> implementing so that I could rely upon tail calls and so forth. Does
> Scarcity
> require the GC code to be written entirely in C?
>
> Finally, do you have any references describing the techniques you have used
> to
> implement a concurrent GC? I have been reading up on the subject for
> several
> years now, with a view to implementing my own concurrent GC.
>
> --
> Dr Jon Harrop, Flying Frog Consultancy Ltd.
> http://www.ffconsultancy.com/?e
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>



-- 
Granville Barnett
http://gbarnett.github.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090618/cc43709d/attachment.html>

From phrosty at gmail.com  Thu Jun 18 04:28:57 2009
From: phrosty at gmail.com (Cory Nelson)
Date: Thu, 18 Jun 2009 04:28:57 -0700
Subject: [LLVMdev] Garbage Collection Project
In-Reply-To: <80a70730906180314g3dc74350hf16d31bd5852c70f@mail.gmail.com>
References: <4A373DAC.9060807@gmail.com>
	<200906180827.54686.jon@ffconsultancy.com>
	<80a70730906180314g3dc74350hf16d31bd5852c70f@mail.gmail.com>
Message-ID: <9b1d06140906180428h4663d9a1u4876e96bdb7d9980@mail.gmail.com>

On Thu, Jun 18, 2009 at 3:14 AM, Granville
Barnett<granvillebarnett at googlemail.com> wrote:
>
>> Firstly, rather than using a single 1 word pointer to represent a
>> reference I
>> chose to use 3 words including a pointer to the type and a pointer to the
>> value (as well as metadata). This allows typed nulls and that addresses an
>> important deficiency found in most other VMs including the CLR. Is
>> Scarcity
>> able to handle such references or does its implementation of stack frames
>> require references to be a single word?
>
> Three words sounds pretty expensive to me, I can see the use of an extra
> word for typed nulls. If you look at something like the CLR you will see
> that you have very fast access to an objects type, after all when you have a
> reference to an object what you really have is a reference to an objects'
> object header. From there you can access an objects syncblock (if it has
> one, which is before the obj header) and the objects' method table which
> includes the relevant pointers to the objects' type among other things. It
> simply means you do a few hops, each of which is a constant operation
> anyway.
>
> Maybe I'm missing something key about the language you are implementing the
> GC for, also is it really necessary to use an extra word for null types?

I'm also curious what language uses this and why it is useful :)
Also, things like this would make lock-free algorithms difficult or impossible.

-- 
Cory Nelson


From the.dead.shall.rise at gmail.com  Thu Jun 18 04:30:06 2009
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Thu, 18 Jun 2009 13:30:06 +0200
Subject: [LLVMdev] llvmc for PIC16
In-Reply-To: <4A39F1D7.4060101@microchip.com>
References: <4A2633E9.4070207@microchip.com>
	<loom.20090604T142600-116@post.gmane.org>
	<4A28C062.9060307@microchip.com>
	<loom.20090607T070933-452@post.gmane.org>
	<4A35EA76.7090602@microchip.com>
	<3cb898890906150348l2e0d4095seb54de38f95e69f9@mail.gmail.com>
	<4A3656A3.1050403@microchip.com>
	<3cb898890906150730k534167dfxf59677e966477220@mail.gmail.com>
	<4A39F1D7.4060101@microchip.com>
Message-ID: <3cb898890906180430k5cb0d57fh7c66d10a45c50db0@mail.gmail.com>

Hi Sanjiv,

2009/6/18 Sanjiv Gupta <sanjiv.gupta at microchip.com>:
> Hi Mikhail,
> Thanks for your wonderful help so far. I have few more questions to ask:
>
> How do I modify the driver to pick tools from where the driver itself
> resides, rather than from the PATH?
> Do I need to write some C++ code to customize such behaviors?

Yes, this is what hooks are for. You're supposed to change the
cmd_line property to something like this:

(cmd_line "$CALL(PrependCustomizedPath, 'toolname') --tool --options")

The PrependCustomizedPath function above is implemented in C++ (just
drop a .cpp file into the plugin directory).

> And how to make sure that we have same behavior on Windows as far as paths
> (/ Vs \) and  picking up tools from the driver directory is concerned?

Right now, you can't do OS detection in TableGen code, so you should
use hooks for platform-specific things.

Also, do not hesitate to mail me or file a bug if you notice some
warts in Windows support. One known issue is that DLL plugins do not
work. I test on both Linux and Windows, but develop mainly on Linux.

BTW, Chris's Makefile changes broke llvmc yesterday (r75379). I'm
working on a fix.

-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments


From mdevan.foobar at gmail.com  Thu Jun 18 04:31:23 2009
From: mdevan.foobar at gmail.com (Mahadevan R)
Date: Thu, 18 Jun 2009 17:01:23 +0530
Subject: [LLVMdev] Query on optimizing away function calls.
Message-ID: <c8033d570906180431o6fd7dc8av7e6db3405bd5ea32@mail.gmail.com>

Hi Duncan,

> Message: 15
> Date: Thu, 18 Jun 2009 10:58:47 +0200
> From: Duncan Sands <baldrick at free.fr>
> Subject: Re: [LLVMdev] Query on optimizing away function calls.
> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Message-ID: <4A3A01C7.8020707 at free.fr>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi,
>
> > Consider the following code:
> >
> > ------------
> > define void @func() {
> >    %a = alloca i32
> >    store i32 42, i32* %a
> >    call void @func2(i32* %a) nounwind
> >    ret void
> > }
> >
> > define void @func2(i32* %a) nounwind {
> >    store i32 43, i32* %a
> >    ret void
> > }
> > ------------
> >
> > It is possible to optimize this to:
> >
> > ------------
> > define void @func() {
> >        ret void
> > }
> >
> > define void @func2(i32* %a) nounwind {
> >        store i32 43, i32* %a
> >        ret void
> > }
> > ------------
> >
> > which is just what I want. However, if @func2 is implemented in an external C
> > library, is this not possible? Specifically, while optimizing:
> >
> > ------------
> > define void @func() {
> >    %a = alloca i32
> >    store i32 42, i32* %a
> >    call void @func2(i32* %a) nounwind
> >    ret void
> > }
> >
> > declare void @func2(i32* %a) nounwind
> > ------------
> >
> > is there some way to specify that @func2 only modifies values accessible via %a,
> > so that if all those values are ultimately discarded then the call to @func2
> > itself can be discarded?
>
> no, there is currently no way.  There was some discussion of adding
> attributes for this, but I think the conclusion was that there were
> too many hairy details for not enough gain.
>
> > The "readonly" function attribute looks to be too strict for this.
>
> It is possible to put "readonly" on the call, rather than on func2
> itself.  So if your front-end somehow knows that this use of func2
> has no real effect it could mark the call this way.


Here's where this question comes from, may be this use case inspires
someone :-). I've a "big.int", that should behave like an i32. The
big.int routines are provided by a C runtime. To illustrate:

----------------------
; int func(int a, int b) { int c = a; return b; }

; using a regular int
define i32 @func1(i32 %a, i32 %b) {
    %cp = alloca i32
    store i32 %a, i32* %cp
    ret i32 %b
}

%big.int = type { i32, i32, i32* }

; using this big.int
define %big.int* @func2(%big.int* %a, %big.int* %b) {
    %cp = alloca %big.int
    call void @big.int.copy.ctor(%big.int* %cp, %big.int* %b) nounwind
    call void @big.int.dtor(%big.int* %cp) nounwind
    ret %big.int* %b
}

declare void @big.int.copy.ctor(%big.int*, %big.int*) nounwind
declare void @big.int.dtor(%big.int*) nounwind
----------------------

LLVM being able to optimize away the unnecessary temp object would be a
big win here.

The only way for my frontend to know that the temp is unnecessary is to
track values using use-defs, and well, you know, implement that function
attribute :-). The frontend would now need passes, pass managers..

Another, more elegant way would be to somehow be able to plugin a type,
like i32, at runtime, into LLVM, so that the front end can say naughty things
like:

----------------------
; using a big int, and magic!
define %ext.big.int @func1(%ext.big.int %a, %ext.big.int %b) {
    %cp = alloca %ext.big.int
    store %ext.big.int %a, %ext.big.int* %cp
    ret %ext.big.int %b
}
----------------------

And maybe have a final pass take care of expanding those things into
big.int.* calls. Something of that sort.

>From what I've experimented so far, looks like if a language were to use
exclusively a big.int instead of say i32, the effectiveness of LLVM's
optimizations are low (please correct me if I'm wrong). (My real-life big
int is naturally a wrapper over GMP, which means it can't be "written" in
LLVM. Writing *everything* in LLVM would solve *everything*, of course :-)

My apologies if I haven't done enough homework, any pointers are appreciated.

Thanks & Regards,
-Mahadevan.

>
> > Or am I missing something obvious?
>
> Nope.
>
> Ciao,
>
> Duncan.
>



From jon at ffconsultancy.com  Thu Jun 18 06:04:08 2009
From: jon at ffconsultancy.com (Jon Harrop)
Date: Thu, 18 Jun 2009 14:04:08 +0100
Subject: [LLVMdev] Garbage Collection Project
In-Reply-To: <80a70730906180314g3dc74350hf16d31bd5852c70f@mail.gmail.com>
References: <4A373DAC.9060807@gmail.com>
	<200906180827.54686.jon@ffconsultancy.com>
	<80a70730906180314g3dc74350hf16d31bd5852c70f@mail.gmail.com>
Message-ID: <200906181404.09001.jon@ffconsultancy.com>

On Thursday 18 June 2009 11:14:35 Granville Barnett wrote:
> > Firstly, rather than using a single 1 word pointer to represent a
> > reference I
> > chose to use 3 words including a pointer to the type and a pointer to the
> > value (as well as metadata). This allows typed nulls and that addresses
> > an important deficiency found in most other VMs including the CLR. Is
> > Scarcity able to handle such references or does its implementation of
> > stack frames require references to be a single word?
>
> Three words sounds pretty expensive to me, I can see the use of an extra
> word for typed nulls.

The word is not really "extra" because I just moved the header out of the 
value and into the reference. For example, the three words for an array are a 
pointer to the type, the array length and a pointer to the (C-compatible) 
array data. In addition to providing typed nulls, this has the added 
advantage of simplifying interop.

> If you look at something like the CLR you will see 
> that you have very fast access to an objects type, after all when you have
> a reference to an object what you really have is a reference to an objects'
> object header. From there you can access an objects syncblock (if it has
> one, which is before the obj header) and the objects' method table which
> includes the relevant pointers to the objects' type among other things. It
> simply means you do a few hops, each of which is a constant operation
> anyway.

That is similar to the approach I used, although HLVM provides a pointer 
directly to the type, saving you a single hop.

> Maybe I'm missing something key about the language you are implementing the
> GC for, also is it really necessary to use an extra word for null types?

I would not have considered it had I not seen the damage done to F# by the 
CLR's typeless nulls. You want an unallocated constant for many different 
purposes in F#, such as representing the empty option type None, the empty 
list [] and maybe the unit value (). Unfortunately, using "null" means you 
don't get any type information and that means that none of those values work 
correctly with anything requiring run-time type information such as generic 
printing, serialization and so on. The only alternative is to use an 
allocated value but the allocator and (concurrent) GC are very slow so that 
gives you the functionality you want but only at a grave cost in terms of 
performance.

Consequently, they chose to represent the empty list with an allocated value 
(so [] prints correctly) but the option type uses null. Hence printf "%A" 
None prints "<null>". They've also used other tricks like having an internal 
set representation that uses nulls but is wrapped in another representation 
that handles them correctly but only at the cost of an extra level of 
indirection.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e


From jon at ffconsultancy.com  Thu Jun 18 06:11:20 2009
From: jon at ffconsultancy.com (Jon Harrop)
Date: Thu, 18 Jun 2009 14:11:20 +0100
Subject: [LLVMdev] Garbage Collection Project
In-Reply-To: <9b1d06140906180428h4663d9a1u4876e96bdb7d9980@mail.gmail.com>
References: <4A373DAC.9060807@gmail.com>
	<80a70730906180314g3dc74350hf16d31bd5852c70f@mail.gmail.com>
	<9b1d06140906180428h4663d9a1u4876e96bdb7d9980@mail.gmail.com>
Message-ID: <200906181411.20476.jon@ffconsultancy.com>

On Thursday 18 June 2009 12:28:57 Cory Nelson wrote:
> I'm also curious what language uses this and why it is useful :)

HLVM is intended to be a general-purpose VM rather than a particular language.

> Also, things like this would make lock-free algorithms difficult or
> impossible.

True. Perhaps that is a good argument for providing both kinds. However, nulls 
are certainly more common than concurrent data structures. :-)

The entire source code for HLVM is available for free under a 
commerce-friendly BSD license, BTW:

  http://forge.ocamlcore.org/projects/hlvm/

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e


From baldrick at free.fr  Thu Jun 18 05:23:46 2009
From: baldrick at free.fr (Duncan Sands)
Date: Thu, 18 Jun 2009 14:23:46 +0200
Subject: [LLVMdev] Query on optimizing away function calls.
In-Reply-To: <c8033d570906180431o6fd7dc8av7e6db3405bd5ea32@mail.gmail.com>
References: <c8033d570906180431o6fd7dc8av7e6db3405bd5ea32@mail.gmail.com>
Message-ID: <4A3A31D2.7030305@free.fr>

Hi,

> Here's where this question comes from, may be this use case inspires
> someone :-). I've a "big.int", that should behave like an i32. The
> big.int routines are provided by a C runtime. To illustrate:
> 
> ----------------------
> ; int func(int a, int b) { int c = a; return b; }
> 
> ; using a regular int
> define i32 @func1(i32 %a, i32 %b) {
>     %cp = alloca i32
>     store i32 %a, i32* %cp
>     ret i32 %b
> }
> 
> %big.int = type { i32, i32, i32* }
> 
> ; using this big.int
> define %big.int* @func2(%big.int* %a, %big.int* %b) {
>     %cp = alloca %big.int
>     call void @big.int.copy.ctor(%big.int* %cp, %big.int* %b) nounwind
>     call void @big.int.dtor(%big.int* %cp) nounwind
>     ret %big.int* %b
> }
> 
> declare void @big.int.copy.ctor(%big.int*, %big.int*) nounwind
> declare void @big.int.dtor(%big.int*) nounwind
> ----------------------
> 
> LLVM being able to optimize away the unnecessary temp object would be a
> big win here.

I don't see how it can be.  Presumably the @big.int.dtor really does
something, like freeing memory.  It has to be run, no?

Ciao,

Duncan.


From e0325716 at student.tuwien.ac.at  Thu Jun 18 06:22:44 2009
From: e0325716 at student.tuwien.ac.at (Andreas Neustifter)
Date: Thu, 18 Jun 2009 15:22:44 +0200
Subject: [LLVMdev] Initialising global Array
Message-ID: <4A3A3FA4.20101@student.tuwien.ac.at>

Hi,

I try to create a array that has a nonzero initialiser:

What i do is, first create the array type.

 > const ArrayType *ATy = ArrayType::get(Type::Int32Ty, NumEdges);

Then create some constant values for the initializer.

 > std::vector<Constant*> Initializer; Initializer.reserve(NumEdges);
 > APInt zero(32,0);      Constant* zeroc = ConstantInt::get(zero);
 > APInt minusone(32,-1); Constant* minusonec = ConstantInt::get(minusone);

Create the global array, there is no initializer yet.

 > GlobalVariable *Counters =
 >   new GlobalVariable(ATy, false, GlobalValue::InternalLinkage,
 >                      Constant::getNullValue(ATy), "OptimalEdgeProfCounters", &M);

Then exactly "NumEdges" constants are pushed to the "Initializer":

 > Initializer[i] = zeroc;
 > ..
 > Initializer[i] = minusonec;
 > ..

And then I set the initializer for the array:

 > Constant *init = llvm::ConstantArray::get(ATy, Initializer);
 > Counters->setInitializer(init);


What am I doing wrong? I still get:

 > @OptimalEdgeProfCounters = internal global [2 x i32] zeroinitializer; <[2 x i32]*> [#uses=2]

Thanks, Andi



From mcheva at cs.mcgill.ca  Thu Jun 18 06:48:55 2009
From: mcheva at cs.mcgill.ca (Nyx)
Date: Thu, 18 Jun 2009 06:48:55 -0700 (PDT)
Subject: [LLVMdev]  Explicitly Freeing Allocas
Message-ID: <24093351.post@talk.nabble.com>


Hello,

I would just like to ask if it's possible to explicitly free allocas. This
is because I need to call functions that take structs of different sizes as
input, (possibly inside of loops) and I would rather avoid a stack overflow.

If this is not possible, an alternate solution would be for me to allocate
an array of bytes larger than all the struct types I may be using, and cast
that pointer to the right type each type. In that case, I would like to know
how I can find out what the size of a struct is. I've heard of people
talking about using "the right target data", but I have no idea how to
actually do that, and I find the doxygen info doesn't make it any clearer.

Thank you for your help,

- Max
-- 
View this message in context: http://www.nabble.com/Explicitly-Freeing-Allocas-tp24093351p24093351.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.



From criswell at cs.uiuc.edu  Thu Jun 18 07:15:25 2009
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu, 18 Jun 2009 09:15:25 -0500
Subject: [LLVMdev] Explicitly Freeing Allocas
In-Reply-To: <24093351.post@talk.nabble.com>
References: <24093351.post@talk.nabble.com>
Message-ID: <4A3A4BFD.6050603@cs.uiuc.edu>

Nyx wrote:
> Hello,
>
> I would just like to ask if it's possible to explicitly free allocas. This
> is because I need to call functions that take structs of different sizes as
> input, (possibly inside of loops) and I would rather avoid a stack overflow.
>   
No, it's not legal to free memory returned by alloca.  Such memory is
allocated on the stack; the code generator usually converts this to an
adjustment of the stack pointer on function entry whenever possible.
> If this is not possible, an alternate solution would be for me to allocate
> an array of bytes larger than all the struct types I may be using, and cast
> that pointer to the right type each type. In that case, I would like to know
> how I can find out what the size of a struct is. I've heard of people
> talking about using "the right target data", but I have no idea how to
> actually do that, and I find the doxygen info doesn't make it any clearer.
>   
This sounds like your best option.  The TargetData pass is a pass that
informs other passes of  machine specific information and can, for
example, give you the number of bytes used to store a type.

Read the document on Writing an LLVM Pass
(http://llvm.org/docs/WritingAnLLVMPass.html) to learn how to have your
pass declare the TargetData pass as a prerequisite and to get a pointer
to it when your
runOnFunction/runOnModule/runOnBasicBlock/runOn<whatever> method is
called.  Then use the doxygen documentation to find the correct method
of the TargetData pass 
(http://llvm.org/doxygen/classllvm_1_1TargetData.html) to use to get the
size of the type that you allocated via alloca.

-- John T.
 
> Thank you for your help,
>
> - Max
>   



From granvillebarnett at googlemail.com  Thu Jun 18 07:29:38 2009
From: granvillebarnett at googlemail.com (Granville Barnett)
Date: Thu, 18 Jun 2009 15:29:38 +0100
Subject: [LLVMdev] Garbage Collection Project
In-Reply-To: <200906181411.20476.jon@ffconsultancy.com>
References: <4A373DAC.9060807@gmail.com>
	<80a70730906180314g3dc74350hf16d31bd5852c70f@mail.gmail.com>
	<9b1d06140906180428h4663d9a1u4876e96bdb7d9980@mail.gmail.com>
	<200906181411.20476.jon@ffconsultancy.com>
Message-ID: <80a70730906180729l6307fb93tc384f3e31ba0ce2d@mail.gmail.com>

>
> That is similar to the approach I used, although HLVM provides a pointer

directly to the type, saving you a single hop.


I'm not so sure that is a very good reason, depending on your implementation
data structures that are fundamental to the type system of the virtual
machine use custom allocators so the extra hop carries little to no expense.

I would not have considered it had I not seen the damage done to F# by the

CLR's typeless nulls. You want an unallocated constant for many different

purposes in F#, such as representing the empty option type None, the empty

list [] and maybe the unit value (). Unfortunately, using "null" means you

don't get any type information and that means that none of those values work

correctly with anything requiring run-time type information such as generic

printing, serialization and so on. The only alternative is to use an

allocated value but the allocator and (concurrent) GC are very slow so that

gives you the functionality you want but only at a grave cost in terms of

performance.



> Consequently, they chose to represent the empty list with an allocated
> value

(so [] prints correctly) but the option type uses null. Hence printf "%A"

None prints "<null>". They've also used other tricks like having an internal

set representation that uses nulls but is wrapped in another representation

that handles them correctly but only at the cost of an extra level of

indirection.


I know little to nothing about that so I find it hard to comment.

The only alternative is to use an allocated value but the allocator and
> (concurrent) GC are very slow so that

gives you the functionality you want but only at a grave cost in terms of

performance


I find this hard to believe, the GC used in CLR 2.0 is very fast. Surely its
only downfall is that it uses a general mark-sweep generational algorithm so
some languages (yours may be one of them) may suffer because of its
generality. It sounds though as if you are using the fast allocator in the
runtime anyway (which most objects do) which is incredibly fast as it does
little to no checks before allocating space for the object.

It may be that your solution cuts some of the time off the GC, but I really
don't think that the GC in the second incarnation of the CLR is slow.

2009/6/18 Jon Harrop <jon at ffconsultancy.com>

> On Thursday 18 June 2009 12:28:57 Cory Nelson wrote:
> > I'm also curious what language uses this and why it is useful :)
>
> HLVM is intended to be a general-purpose VM rather than a particular
> language.
>
> > Also, things like this would make lock-free algorithms difficult or
> > impossible.
>
> True. Perhaps that is a good argument for providing both kinds. However,
> nulls
> are certainly more common than concurrent data structures. :-)
>
> The entire source code for HLVM is available for free under a
> commerce-friendly BSD license, BTW:
>
>  http://forge.ocamlcore.org/projects/hlvm/
>
> --
> Dr Jon Harrop, Flying Frog Consultancy Ltd.
> http://www.ffconsultancy.com/?e
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>



-- 
Granville Barnett
http://gbarnett.github.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090618/155b0703/attachment.html>

From fvbommel at wxs.nl  Thu Jun 18 07:32:00 2009
From: fvbommel at wxs.nl (Frits van Bommel)
Date: Thu, 18 Jun 2009 16:32:00 +0200
Subject: [LLVMdev] Explicitly Freeing Allocas
In-Reply-To: <24093351.post@talk.nabble.com>
References: <24093351.post@talk.nabble.com>
Message-ID: <4A3A4FE0.2030104@wxs.nl>

Nyx wrote:
> Hello,
> 
> I would just like to ask if it's possible to explicitly free allocas. This
> is because I need to call functions that take structs of different sizes as
> input, (possibly inside of loops) and I would rather avoid a stack overflow.

You can't explicitly free a specific alloca, but you can use the llvm.stacksave 
and llvm.stackrestore intrinsics to free all allocas performed after calling the 
stacksave intrinsic.

http://llvm.org/docs/LangRef.html#int_stacksave


From granvillebarnett at googlemail.com  Thu Jun 18 07:45:43 2009
From: granvillebarnett at googlemail.com (Granville Barnett)
Date: Thu, 18 Jun 2009 15:45:43 +0100
Subject: [LLVMdev] Garbage Collection Project
In-Reply-To: <80a70730906180729l6307fb93tc384f3e31ba0ce2d@mail.gmail.com>
References: <4A373DAC.9060807@gmail.com>
	<80a70730906180314g3dc74350hf16d31bd5852c70f@mail.gmail.com>
	<9b1d06140906180428h4663d9a1u4876e96bdb7d9980@mail.gmail.com>
	<200906181411.20476.jon@ffconsultancy.com>
	<80a70730906180729l6307fb93tc384f3e31ba0ce2d@mail.gmail.com>
Message-ID: <80a70730906180745n49e1e051r9aca8dfb8381493b@mail.gmail.com>

My first point, i.e. the custom allocator was in relation to the fact that
key data structures are allocated to private memory reserved for the runtime
so things tend to be laid out pretty well so the extra hop is not that
expensive. Just thought I'd make that clearer.

2009/6/18 Granville Barnett <granvillebarnett at googlemail.com>

> That is similar to the approach I used, although HLVM provides a pointer
>
> directly to the type, saving you a single hop.
>
>
> I'm not so sure that is a very good reason, depending on your
> implementation data structures that are fundamental to the type system of
> the virtual machine use custom allocators so the extra hop carries little to
> no expense.
>
> I would not have considered it had I not seen the damage done to F# by the
>
> CLR's typeless nulls. You want an unallocated constant for many different
>
> purposes in F#, such as representing the empty option type None, the empty
>
> list [] and maybe the unit value (). Unfortunately, using "null" means you
>
> don't get any type information and that means that none of those values
>> work
>
> correctly with anything requiring run-time type information such as generic
>
> printing, serialization and so on. The only alternative is to use an
>
> allocated value but the allocator and (concurrent) GC are very slow so that
>
> gives you the functionality you want but only at a grave cost in terms of
>
> performance.
>
>
>
>> Consequently, they chose to represent the empty list with an allocated
>> value
>
> (so [] prints correctly) but the option type uses null. Hence printf "%A"
>
> None prints "<null>". They've also used other tricks like having an
>> internal
>
> set representation that uses nulls but is wrapped in another representation
>
> that handles them correctly but only at the cost of an extra level of
>
> indirection.
>
>
> I know little to nothing about that so I find it hard to comment.
>
> The only alternative is to use an allocated value but the allocator and
>> (concurrent) GC are very slow so that
>
>  gives you the functionality you want but only at a grave cost in terms of
>>
>
>  performance
>
>
> I find this hard to believe, the GC used in CLR 2.0 is very fast. Surely
> its only downfall is that it uses a general mark-sweep generational
> algorithm so some languages (yours may be one of them) may suffer because of
> its generality. It sounds though as if you are using the fast allocator in
> the runtime anyway (which most objects do) which is incredibly fast as it
> does little to no checks before allocating space for the object.
>
> It may be that your solution cuts some of the time off the GC, but I really
> don't think that the GC in the second incarnation of the CLR is slow.
>
> 2009/6/18 Jon Harrop <jon at ffconsultancy.com>
>
>> On Thursday 18 June 2009 12:28:57 Cory Nelson wrote:
>>
>> > I'm also curious what language uses this and why it is useful :)
>>
>> HLVM is intended to be a general-purpose VM rather than a particular
>> language.
>>
>> > Also, things like this would make lock-free algorithms difficult or
>> > impossible.
>>
>> True. Perhaps that is a good argument for providing both kinds. However,
>> nulls
>> are certainly more common than concurrent data structures. :-)
>>
>> The entire source code for HLVM is available for free under a
>> commerce-friendly BSD license, BTW:
>>
>>  http://forge.ocamlcore.org/projects/hlvm/
>>
>> --
>> Dr Jon Harrop, Flying Frog Consultancy Ltd.
>> http://www.ffconsultancy.com/?e
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
>
>
> --
> Granville Barnett
> http://gbarnett.github.com
>



-- 
Granville Barnett
http://gbarnett.github.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090618/01acc52b/attachment.html>

From mcheva at cs.mcgill.ca  Thu Jun 18 08:08:30 2009
From: mcheva at cs.mcgill.ca (Nyx)
Date: Thu, 18 Jun 2009 08:08:30 -0700 (PDT)
Subject: [LLVMdev] Explicitly Freeing Allocas
In-Reply-To: <4A3A4BFD.6050603@cs.uiuc.edu>
References: <24093351.post@talk.nabble.com> <4A3A4BFD.6050603@cs.uiuc.edu>
Message-ID: <24094996.post@talk.nabble.com>


That sounds rather cumbersome, is there no simpler way to get the actual size
of a struct?


John Criswell wrote:
> 
> Nyx wrote:
>> Hello,
>>
>> I would just like to ask if it's possible to explicitly free allocas.
>> This
>> is because I need to call functions that take structs of different sizes
>> as
>> input, (possibly inside of loops) and I would rather avoid a stack
>> overflow.
>>   
> No, it's not legal to free memory returned by alloca.  Such memory is
> allocated on the stack; the code generator usually converts this to an
> adjustment of the stack pointer on function entry whenever possible.
>> If this is not possible, an alternate solution would be for me to
>> allocate
>> an array of bytes larger than all the struct types I may be using, and
>> cast
>> that pointer to the right type each type. In that case, I would like to
>> know
>> how I can find out what the size of a struct is. I've heard of people
>> talking about using "the right target data", but I have no idea how to
>> actually do that, and I find the doxygen info doesn't make it any
>> clearer.
>>   
> This sounds like your best option.  The TargetData pass is a pass that
> informs other passes of  machine specific information and can, for
> example, give you the number of bytes used to store a type.
> 
> Read the document on Writing an LLVM Pass
> (http://llvm.org/docs/WritingAnLLVMPass.html) to learn how to have your
> pass declare the TargetData pass as a prerequisite and to get a pointer
> to it when your
> runOnFunction/runOnModule/runOnBasicBlock/runOn<whatever> method is
> called.  Then use the doxygen documentation to find the correct method
> of the TargetData pass 
> (http://llvm.org/doxygen/classllvm_1_1TargetData.html) to use to get the
> size of the type that you allocated via alloca.
> 
> -- John T.
>  
>> Thank you for your help,
>>
>> - Max
>>   
> 
> _______________________________________________
> 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://www.nabble.com/Explicitly-Freeing-Allocas-tp24093351p24094996.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.



From mcheva at cs.mcgill.ca  Thu Jun 18 08:12:18 2009
From: mcheva at cs.mcgill.ca (Nyx)
Date: Thu, 18 Jun 2009 08:12:18 -0700 (PDT)
Subject: [LLVMdev] Explicitly Freeing Allocas
In-Reply-To: <4A3A4FE0.2030104@wxs.nl>
References: <24093351.post@talk.nabble.com> <4A3A4FE0.2030104@wxs.nl>
Message-ID: <24095072.post@talk.nabble.com>


What kind of overhead does that have? Does it only restore the stack pointer
to what it was (what I want), or does it do more than that, and try to
restore values that were on the stack prior to save, etc?


Frits van Bommel wrote:
> 
> Nyx wrote:
>> Hello,
>> 
>> I would just like to ask if it's possible to explicitly free allocas.
>> This
>> is because I need to call functions that take structs of different sizes
>> as
>> input, (possibly inside of loops) and I would rather avoid a stack
>> overflow.
> 
> You can't explicitly free a specific alloca, but you can use the
> llvm.stacksave 
> and llvm.stackrestore intrinsics to free all allocas performed after
> calling the 
> stacksave intrinsic.
> 
> http://llvm.org/docs/LangRef.html#int_stacksave
> _______________________________________________
> 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://www.nabble.com/Explicitly-Freeing-Allocas-tp24093351p24095072.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.



From baldrick at free.fr  Thu Jun 18 08:15:42 2009
From: baldrick at free.fr (Duncan Sands)
Date: Thu, 18 Jun 2009 17:15:42 +0200
Subject: [LLVMdev] Explicitly Freeing Allocas
In-Reply-To: <24093351.post@talk.nabble.com>
References: <24093351.post@talk.nabble.com>
Message-ID: <4A3A5A1E.8010301@free.fr>

Hi,

> If this is not possible, an alternate solution would be for me to allocate
> an array of bytes larger than all the struct types I may be using, and cast
> that pointer to the right type each type. In that case, I would like to know
> how I can find out what the size of a struct is. I've heard of people
> talking about using "the right target data", but I have no idea how to
> actually do that, and I find the doxygen info doesn't make it any clearer.

you can get the size in a target independent way using
ConstantExpr::getSizeOf.  You can also get the alignment
using ConstantExpr::getAlignOf, but this is less useful.

Ciao,

Duncan.


From meurant.olivier at gmail.com  Thu Jun 18 08:15:54 2009
From: meurant.olivier at gmail.com (Olivier Meurant)
Date: Thu, 18 Jun 2009 17:15:54 +0200
Subject: [LLVMdev] Explicitly Freeing Allocas
In-Reply-To: <24094996.post@talk.nabble.com>
References: <24093351.post@talk.nabble.com> <4A3A4BFD.6050603@cs.uiuc.edu>
	<24094996.post@talk.nabble.com>
Message-ID: <549cee610906180815v7a39a0cg3c936e50f5145a51@mail.gmail.com>

In the TargetData class (available from you ExecutionEngine), you have some
informations available (such as StructLayout...).


On Thu, Jun 18, 2009 at 5:08 PM, Nyx <mcheva at cs.mcgill.ca> wrote:

>
> That sounds rather cumbersome, is there no simpler way to get the actual
> size
> of a struct?
>
>
> John Criswell wrote:
> >
> > Nyx wrote:
> >> Hello,
> >>
> >> I would just like to ask if it's possible to explicitly free allocas.
> >> This
> >> is because I need to call functions that take structs of different sizes
> >> as
> >> input, (possibly inside of loops) and I would rather avoid a stack
> >> overflow.
> >>
> > No, it's not legal to free memory returned by alloca.  Such memory is
> > allocated on the stack; the code generator usually converts this to an
> > adjustment of the stack pointer on function entry whenever possible.
> >> If this is not possible, an alternate solution would be for me to
> >> allocate
> >> an array of bytes larger than all the struct types I may be using, and
> >> cast
> >> that pointer to the right type each type. In that case, I would like to
> >> know
> >> how I can find out what the size of a struct is. I've heard of people
> >> talking about using "the right target data", but I have no idea how to
> >> actually do that, and I find the doxygen info doesn't make it any
> >> clearer.
> >>
> > This sounds like your best option.  The TargetData pass is a pass that
> > informs other passes of  machine specific information and can, for
> > example, give you the number of bytes used to store a type.
> >
> > Read the document on Writing an LLVM Pass
> > (http://llvm.org/docs/WritingAnLLVMPass.html) to learn how to have your
> > pass declare the TargetData pass as a prerequisite and to get a pointer
> > to it when your
> > runOnFunction/runOnModule/runOnBasicBlock/runOn<whatever> method is
> > called.  Then use the doxygen documentation to find the correct method
> > of the TargetData pass
> > (http://llvm.org/doxygen/classllvm_1_1TargetData.html) to use to get the
> > size of the type that you allocated via alloca.
> >
> > -- John T.
> >
> >> Thank you for your help,
> >>
> >> - Max
> >>
> >
> > _______________________________________________
> > 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://www.nabble.com/Explicitly-Freeing-Allocas-tp24093351p24094996.html
> Sent from the LLVM - Dev mailing list archive at Nabble.com.
>
> _______________________________________________
> 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.llvm.org/pipermail/llvm-dev/attachments/20090618/d2cb677d/attachment.html>

From fvbommel at wxs.nl  Thu Jun 18 09:19:35 2009
From: fvbommel at wxs.nl (Frits van Bommel)
Date: Thu, 18 Jun 2009 18:19:35 +0200
Subject: [LLVMdev] Explicitly Freeing Allocas
In-Reply-To: <24095072.post@talk.nabble.com>
References: <24093351.post@talk.nabble.com> <4A3A4FE0.2030104@wxs.nl>
	<24095072.post@talk.nabble.com>
Message-ID: <4A3A6917.1080705@wxs.nl>

Nyx wrote:
[re: llvm.stacksave & stackrestore]
> What kind of overhead does that have? Does it only restore the stack pointer
> to what it was (what I want), or does it do more than that, and try to
> restore values that were on the stack prior to save, etc?

It basically just copies and restores the stack pointer, though I guess the 
langref isn't exactly very clear on that point.


From dag at cray.com  Thu Jun 18 09:23:24 2009
From: dag at cray.com (David Greene)
Date: Thu, 18 Jun 2009 11:23:24 -0500
Subject: [LLVMdev] LLVM Dev Mtg
Message-ID: <200906181123.24394.dag@cray.com>

I saw Tanya's note about this year's LLVM developers' meeting.
It would be interesting if the time could coincide with IDF
2009 (Sep. 22-24).  I'm sure some LLVM folks would be interested
in attending IDF as well.  Perhaps hold the LLVM conference the
day before or after IDF?

                               -Dave


From dag at cray.com  Thu Jun 18 09:42:46 2009
From: dag at cray.com (David Greene)
Date: Thu, 18 Jun 2009 11:42:46 -0500
Subject: [LLVMdev] Regular Expressions
In-Reply-To: <6075EAC5-AFD5-4239-9ACD-CEDB449CE576@apple.com>
References: <200906081700.n58H0Zvi022899@zion.cs.uiuc.edu>
	<200906161949.47079.dag@cray.com>
	<6075EAC5-AFD5-4239-9ACD-CEDB449CE576@apple.com>
Message-ID: <200906181142.46506.dag@cray.com>

On Wednesday 17 June 2009 01:06, Chris Lattner wrote:

> I think I understand what you're saying with "munging strings is
> easier".  However, I still don't understand why you can't pass down
> some 'my_f32' instead of '"f32"' and have the defm pull out the right
> fields from my_f32.  The AVX type would be v8f32, the SSE type would
> be v4f32, etc.
>
> More generally, I don't see how strings can be better in any
> circumstance: in any case where you pass down a string, you can pass
> down a def that has fields relating to how you would otherwise munge
> the string, no?

Ok, I've been refactoring things here a bit and I think what you propose
will work.  I'll run with it and see if I get myself into any trouble.

Thanks for pushing on this.  I think things'll come out better because
of it.

                             -Dave


From sricketts at maxentric.com  Thu Jun 18 10:13:43 2009
From: sricketts at maxentric.com (Scott Ricketts)
Date: Thu, 18 Jun 2009 10:13:43 -0700
Subject: [LLVMdev]  Referring to an argument in another function
Message-ID: <6d9073030906181013n49ae169bu5ce9b1cc5d93cb74@mail.gmail.com>

I would like to instrument certain function calls with a function call
of my own that takes some of the same arguments. For example, I would
like to instrument calls to free with some function foo, so the C code
would look like:

foo(myarg1, myarg2, ptr);
free(ptr);

The problem occurs when I grab the arg from the free function and try
to pass it to foo...

  if (isCallToFree(&I)) {
    Value* P;
    if (Function *F = I.getCalledFunction()) {
      Function::arg_iterator ait = F->arg_begin();
      if (ait) {
        P = &(*ait);
      }
      createCallInst(mem_fcall, &I, 3, getOpcodeValue(I),
                     getInstrIDValue(), P);
    }
  }

createCallInst is my own wrapper. The error thrown during the pass is:

"Referring to an argument in another function!"

Any suggestions?

Thanks,
Scott


From clattner at apple.com  Thu Jun 18 10:32:06 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 18 Jun 2009 10:32:06 -0700
Subject: [LLVMdev] Regular Expressions
In-Reply-To: <200906181142.46506.dag@cray.com>
References: <200906081700.n58H0Zvi022899@zion.cs.uiuc.edu>
	<200906161949.47079.dag@cray.com>
	<6075EAC5-AFD5-4239-9ACD-CEDB449CE576@apple.com>
	<200906181142.46506.dag@cray.com>
Message-ID: <9ECF582F-6E37-4F76-9E85-DE167A44C952@apple.com>


On Jun 18, 2009, at 9:42 AM, David Greene wrote:

> On Wednesday 17 June 2009 01:06, Chris Lattner wrote:
>
>> I think I understand what you're saying with "munging strings is
>> easier".  However, I still don't understand why you can't pass down
>> some 'my_f32' instead of '"f32"' and have the defm pull out the right
>> fields from my_f32.  The AVX type would be v8f32, the SSE type would
>> be v4f32, etc.
>>
>> More generally, I don't see how strings can be better in any
>> circumstance: in any case where you pass down a string, you can pass
>> down a def that has fields relating to how you would otherwise munge
>> the string, no?
>
> Ok, I've been refactoring things here a bit and I think what you  
> propose
> will work.  I'll run with it and see if I get myself into any trouble.
>
> Thanks for pushing on this.  I think things'll come out better because
> of it.

Thank you Dave, I really appreciate your work on this!

-Chris



From pejic at ualberta.ca  Thu Jun 18 11:06:26 2009
From: pejic at ualberta.ca (Slobodan Pejic)
Date: Thu, 18 Jun 2009 12:06:26 -0600
Subject: [LLVMdev] Initialising global Array
In-Reply-To: <4A3A3FA4.20101@student.tuwien.ac.at>
References: <4A3A3FA4.20101@student.tuwien.ac.at>
Message-ID: <4A3A8222.2010603@ualberta.ca>

Andreas Neustifter wrote:
> Hi,
>
> I try to create a array that has a nonzero initialiser:
>
> What i do is, first create the array type.
>
>  > const ArrayType *ATy = ArrayType::get(Type::Int32Ty, NumEdges);
>
> Then create some constant values for the initializer.
>
>  > std::vector<Constant*> Initializer; Initializer.reserve(NumEdges);
>
>   

I ran the following two functions in a ModulePass.  The Initializer 
initialization is the difference.


static void andiTest1(Module &M) {
  int NumEdges = 4;
  const ArrayType *ATy = ArrayType::get(Type::Int32Ty, NumEdges);

  std::vector<Constant*> Initializer; Initializer.reserve(NumEdges);
  APInt zero(32,0);      Constant* zeroc = ConstantInt::get(zero);
  APInt minusone(32,-1); Constant* minusonec = ConstantInt::get(minusone);

  GlobalVariable *Counters = new GlobalVariable(ATy, false,
      GlobalValue::InternalLinkage, Constant::getNullValue(ATy),
      "OptimalEdgeProfCounters1", &M);

  Initializer[0] = zeroc;
  Initializer[1] = minusonec;
  Initializer[2] = minusonec;
  Initializer[3] = zeroc;

  Constant *init = llvm::ConstantArray::get(ATy, Initializer);
  Counters->setInitializer(init);
  DOUT << "Initializer:: \n";
  for( int i = 0; i < Initializer.size(); ++i ) {
    DOUT << "Initializer["<<i<<"]: " << Initializer[i] << "\n";
  }
}

static void andiTest2(Module &M) {
  int NumEdges = 4;
  const ArrayType *ATy = ArrayType::get(Type::Int32Ty, NumEdges);

  std::vector<Constant*> Initializer = std::vector<Constant*>(NumEdges);
  APInt zero(32,0);      Constant* zeroc = ConstantInt::get(zero);
  APInt minusone(32,-1); Constant* minusonec = ConstantInt::get(minusone);

  GlobalVariable *Counters = new GlobalVariable(ATy, false,
      GlobalValue::InternalLinkage, Constant::getNullValue(ATy),
      "OptimalEdgeProfCounters2", &M);

  Initializer[0] = zeroc;
  Initializer[1] = minusonec;
  Initializer[2] = minusonec;
  Initializer[3] = zeroc;

  Constant *init = llvm::ConstantArray::get(ATy, Initializer);
  Counters->setInitializer(init);
  DOUT << "Initializer:: \n";
  for( int i = 0; i < Initializer.size(); ++i ) {
    DOUT << "Initializer["<<i<<"]: " << Initializer[i] << "\n";
  }
}


From juanc.martinez.santos at gmail.com  Thu Jun 18 12:05:35 2009
From: juanc.martinez.santos at gmail.com (Juan Carlos Martinez Santos)
Date: Thu, 18 Jun 2009 15:05:35 -0400
Subject: [LLVMdev] Unknown pseudo-op with -march=arm
Message-ID: <d17b77a40906181205i3a08f39fw65ad6c6b23365857@mail.gmail.com>

Hello,

Running some examples to see how LLVM work, I found that some pseudo
operations are unknown. Details are shown below.

This is the command sequence that I am using:

> llvm-gcc -O3 -emit-llvm hello.c -c -o hello.bc
> llc -march=arm hello.bc -o hello-arm.s
> arm-linux-gcc hello-arm.s -o hello-arm

************************
hello.s:6: Error: Unknown pseudo-op:  `.eabi_attribute'
hello.s:25: Warning: Unrecognized .section attribute: want a,w,x
hello.s:25: Warning: Unrecognized .section attribute: want a,w,x
hello.s:25: Error: Rest of line ignored. First ignored character is `,'.
************************
Assembly Code - part
************************
    .file    "hello.bc"
    .eabi_attribute 20, 1               *** [line 6]
...
    .size main, .-main
    .type .str,%object
    .section    .rodata.str1.1,"aMS",%progbits,1           *** [line 25]
.str:                @ .str
    .size .str, 12
...
************************

Thanks in advance.

-- 
Juan Carlos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090618/e8a3d91a/attachment.html>

From anton at korobeynikov.info  Thu Jun 18 12:30:38 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Thu, 18 Jun 2009 23:30:38 +0400
Subject: [LLVMdev] Unknown pseudo-op with -march=arm
In-Reply-To: <d17b77a40906181205i3a08f39fw65ad6c6b23365857@mail.gmail.com>
References: <d17b77a40906181205i3a08f39fw65ad6c6b23365857@mail.gmail.com>
Message-ID: <b087fca00906181230j6b65f569y6b7e6ec4a5076725@mail.gmail.com>

Hello

> hello.s:6: Error: Unknown pseudo-op:  `.eabi_attribute'
How old is your arm toolchain?

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



From fvbommel at wxs.nl  Thu Jun 18 12:41:38 2009
From: fvbommel at wxs.nl (Frits van Bommel)
Date: Thu, 18 Jun 2009 21:41:38 +0200
Subject: [LLVMdev] Referring to an argument in another function
In-Reply-To: <6d9073030906181013n49ae169bu5ce9b1cc5d93cb74@mail.gmail.com>
References: <6d9073030906181013n49ae169bu5ce9b1cc5d93cb74@mail.gmail.com>
Message-ID: <4A3A9872.8020508@wxs.nl>

Scott Ricketts wrote:
> I would like to instrument certain function calls with a function call
> of my own that takes some of the same arguments. For example, I would
> like to instrument calls to free with some function foo, so the C code
> would look like:
> 
> foo(myarg1, myarg2, ptr);
> free(ptr);
> 
> The problem occurs when I grab the arg from the free function and try
> to pass it to foo...
> 
>   if (isCallToFree(&I)) {
>     Value* P;
>     if (Function *F = I.getCalledFunction()) {
>       Function::arg_iterator ait = F->arg_begin();

You want to look at the operands of the call/invoke/free instruction, not the 
arguments of the function being called.
So if you're sure it's a call or invoke (not a 'free' instruction), try 
something like this:

#include "llvm/Support/CallSite.h"
// ...
         CallSite CS(&I);
         CallSite::arg_iterator ait = CS.arg_begin(), aend = CS.arg_end();

>       if (ait) {

You want
         if (ait != aend) {
here.

>         P = &(*ait);
>       }
>       createCallInst(mem_fcall, &I, 3, getOpcodeValue(I),
>                      getInstrIDValue(), P);
>     }
>   }
> 
> createCallInst is my own wrapper. The error thrown during the pass is:
> 
> "Referring to an argument in another function!"
> 
> Any suggestions?



From mcheva at cs.mcgill.ca  Thu Jun 18 12:47:35 2009
From: mcheva at cs.mcgill.ca (Nyx)
Date: Thu, 18 Jun 2009 12:47:35 -0700 (PDT)
Subject: [LLVMdev] Explicitly Freeing Allocas
In-Reply-To: <549cee610906180815v7a39a0cg3c936e50f5145a51@mail.gmail.com>
References: <24093351.post@talk.nabble.com> <4A3A4BFD.6050603@cs.uiuc.edu>
	<24094996.post@talk.nabble.com>
	<549cee610906180815v7a39a0cg3c936e50f5145a51@mail.gmail.com>
Message-ID: <24099580.post@talk.nabble.com>


I went ahead and implemented the allocation based on the maximum size of all
structs seen so far... The problem is, the TargetData object from
ExecutionEngine gives me a size of 12 for a struct containing a pointer and
an i64 (on a 32-bit machine). However, the generated code seems to assume an
alignment of 8, and tries to read the i64 value at offset 8, which obviously
reads an invalid value.

Does the getSizeInBytes() method from StructLayout not take the alignment
into account?

- Max


Olivier Meurant wrote:
> 
> In the TargetData class (available from you ExecutionEngine), you have
> some
> informations available (such as StructLayout...).
> 
> 
> On Thu, Jun 18, 2009 at 5:08 PM, Nyx <mcheva at cs.mcgill.ca> wrote:
> 
>>
>> That sounds rather cumbersome, is there no simpler way to get the actual
>> size
>> of a struct?
>>
>>
>> John Criswell wrote:
>> >
>> > Nyx wrote:
>> >> Hello,
>> >>
>> >> I would just like to ask if it's possible to explicitly free allocas.
>> >> This
>> >> is because I need to call functions that take structs of different
>> sizes
>> >> as
>> >> input, (possibly inside of loops) and I would rather avoid a stack
>> >> overflow.
>> >>
>> > No, it's not legal to free memory returned by alloca.  Such memory is
>> > allocated on the stack; the code generator usually converts this to an
>> > adjustment of the stack pointer on function entry whenever possible.
>> >> If this is not possible, an alternate solution would be for me to
>> >> allocate
>> >> an array of bytes larger than all the struct types I may be using, and
>> >> cast
>> >> that pointer to the right type each type. In that case, I would like
>> to
>> >> know
>> >> how I can find out what the size of a struct is. I've heard of people
>> >> talking about using "the right target data", but I have no idea how to
>> >> actually do that, and I find the doxygen info doesn't make it any
>> >> clearer.
>> >>
>> > This sounds like your best option.  The TargetData pass is a pass that
>> > informs other passes of  machine specific information and can, for
>> > example, give you the number of bytes used to store a type.
>> >
>> > Read the document on Writing an LLVM Pass
>> > (http://llvm.org/docs/WritingAnLLVMPass.html) to learn how to have your
>> > pass declare the TargetData pass as a prerequisite and to get a pointer
>> > to it when your
>> > runOnFunction/runOnModule/runOnBasicBlock/runOn<whatever> method is
>> > called.  Then use the doxygen documentation to find the correct method
>> > of the TargetData pass
>> > (http://llvm.org/doxygen/classllvm_1_1TargetData.html) to use to get
>> the
>> > size of the type that you allocated via alloca.
>> >
>> > -- John T.
>> >
>> >> Thank you for your help,
>> >>
>> >> - Max
>> >>
>> >
>> > _______________________________________________
>> > 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://www.nabble.com/Explicitly-Freeing-Allocas-tp24093351p24094996.html
>> Sent from the LLVM - Dev mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> 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
> 
> 

-- 
View this message in context: http://www.nabble.com/Explicitly-Freeing-Allocas-tp24093351p24099580.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.



From juanc.martinez.santos at gmail.com  Thu Jun 18 12:49:31 2009
From: juanc.martinez.santos at gmail.com (Juan Carlos Martinez Santos)
Date: Thu, 18 Jun 2009 15:49:31 -0400
Subject: [LLVMdev] Unknown pseudo-op with -march=arm
In-Reply-To: <b087fca00906181230j6b65f569y6b7e6ec4a5076725@mail.gmail.com>
References: <d17b77a40906181205i3a08f39fw65ad6c6b23365857@mail.gmail.com>
	<b087fca00906181230j6b65f569y6b7e6ec4a5076725@mail.gmail.com>
Message-ID: <d17b77a40906181249p4a360d4re8c452b06357d84f@mail.gmail.com>

I am using SimpleScalar cross-compiler 2.95.2 (
http://www.simplescalar.com/v4test.html)


On Thu, Jun 18, 2009 at 3:30 PM, Anton Korobeynikov <anton at korobeynikov.info
> wrote:

> Hello
>
> > hello.s:6: Error: Unknown pseudo-op:  `.eabi_attribute'
> How old is your arm toolchain?
>
> --
> 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
>



-- 
Juan Carlos Martínez Santos
242 Foster Drive Apt H
Colonial Townhouse Apartments
Willimantic, CT 06226-1538
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090618/f3146d69/attachment.html>

From e0325716 at student.tuwien.ac.at  Thu Jun 18 13:07:34 2009
From: e0325716 at student.tuwien.ac.at (Andreas Neustifter)
Date: Thu, 18 Jun 2009 22:07:34 +0200
Subject: [LLVMdev] Initialising global Array
In-Reply-To: <4A3A8222.2010603@ualberta.ca>
References: <4A3A3FA4.20101@student.tuwien.ac.at>
	<4A3A8222.2010603@ualberta.ca>
Message-ID: <4A3A9E86.9000508@student.tuwien.ac.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

Slobodan Pejic wrote:
> I ran the following two functions in a ModulePass.  The Initializer 
> initialization is the difference.
> 
> static void andiTest1(Module &M) {
>   int NumEdges = 4;
>   const ArrayType *ATy = ArrayType::get(Type::Int32Ty, NumEdges);
> 
>   std::vector<Constant*> Initializer; Initializer.reserve(NumEdges);
>   APInt zero(32,0);      Constant* zeroc = ConstantInt::get(zero);
>   APInt minusone(32,-1); Constant* minusonec = ConstantInt::get(minusone);
> 
>   GlobalVariable *Counters = new GlobalVariable(ATy, false,
>       GlobalValue::InternalLinkage, Constant::getNullValue(ATy),
>       "OptimalEdgeProfCounters1", &M);
> 
>   Initializer[0] = zeroc;
>   Initializer[1] = minusonec;
>   Initializer[2] = minusonec;
>   Initializer[3] = zeroc;
> 
>   Constant *init = llvm::ConstantArray::get(ATy, Initializer);
>   Counters->setInitializer(init);
>   DOUT << "Initializer:: \n";
>   for( int i = 0; i < Initializer.size(); ++i ) {
>     DOUT << "Initializer["<<i<<"]: " << Initializer[i] << "\n";
>   }
> }
> 
> static void andiTest2(Module &M) {
>   int NumEdges = 4;
>   const ArrayType *ATy = ArrayType::get(Type::Int32Ty, NumEdges);
> 
>   std::vector<Constant*> Initializer = std::vector<Constant*>(NumEdges);
>   APInt zero(32,0);      Constant* zeroc = ConstantInt::get(zero);
>   APInt minusone(32,-1); Constant* minusonec = ConstantInt::get(minusone);
> 
>   GlobalVariable *Counters = new GlobalVariable(ATy, false,
>       GlobalValue::InternalLinkage, Constant::getNullValue(ATy),
>       "OptimalEdgeProfCounters2", &M);
> 
>   Initializer[0] = zeroc;
>   Initializer[1] = minusonec;
>   Initializer[2] = minusonec;
>   Initializer[3] = zeroc;
> 
>   Constant *init = llvm::ConstantArray::get(ATy, Initializer);
>   Counters->setInitializer(init);
>   DOUT << "Initializer:: \n";
>   for( int i = 0; i < Initializer.size(); ++i ) {
>     DOUT << "Initializer["<<i<<"]: " << Initializer[i] << "\n";
>   }
> }

Yes, the first variant (mine) does not work, the second does. (Don't get
it why, tough...)

But when I use the initialisation of "Initializer" you suggested in my
"production code" it still does not work :-(

But thanks for your effort, I really appreciate it!

Andi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko6nj4ACgkQPiYq0rq7s/DpnQCfflDWnUG/C0qTD1DoltnwbfW9
6g8AmQGfV3PVok15n+5upZShYDlLooGv
=wF1S
-----END PGP SIGNATURE-----


From anton at korobeynikov.info  Thu Jun 18 13:26:44 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Fri, 19 Jun 2009 00:26:44 +0400
Subject: [LLVMdev] Unknown pseudo-op with -march=arm
In-Reply-To: <d17b77a40906181249p4a360d4re8c452b06357d84f@mail.gmail.com>
References: <d17b77a40906181205i3a08f39fw65ad6c6b23365857@mail.gmail.com>
	<b087fca00906181230j6b65f569y6b7e6ec4a5076725@mail.gmail.com>
	<d17b77a40906181249p4a360d4re8c452b06357d84f@mail.gmail.com>
Message-ID: <b087fca00906181326m67ba4d11xd932fdaa9222d480@mail.gmail.com>

> I am using SimpleScalar cross-compiler 2.95.2 (http://www.simplescalar.com/v4test.html)
It's really ancient. Consider upgrading to something not from stone
age :) I doubt you'll be able to assemble anything generated by, for
example, with mainline gcc.

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


From juanc.martinez.santos at gmail.com  Thu Jun 18 14:06:03 2009
From: juanc.martinez.santos at gmail.com (Juan Carlos Martinez Santos)
Date: Thu, 18 Jun 2009 17:06:03 -0400
Subject: [LLVMdev] Unknown pseudo-op with -march=arm
In-Reply-To: <b087fca00906181326m67ba4d11xd932fdaa9222d480@mail.gmail.com>
References: <d17b77a40906181205i3a08f39fw65ad6c6b23365857@mail.gmail.com>
	<b087fca00906181230j6b65f569y6b7e6ec4a5076725@mail.gmail.com>
	<d17b77a40906181249p4a360d4re8c452b06357d84f@mail.gmail.com>
	<b087fca00906181326m67ba4d11xd932fdaa9222d480@mail.gmail.com>
Message-ID: <d17b77a40906181406x3c8672a0t9a5d4a061d81591f@mail.gmail.com>

wow... Tell me, what cross compiler can I use for ARM if I am working in a
i686-Linux machine? At the same time, how I can simulate it?

But the way, If I deleted the unknown pseudo-op and change section .rodata
definition, I can use my stone age cross compiler. I am just wondering why
it works without them.

Thanks in advance.

On Thu, Jun 18, 2009 at 4:26 PM, Anton Korobeynikov <anton at korobeynikov.info
> wrote:

> > I am using SimpleScalar cross-compiler 2.95.2 (
> http://www.simplescalar.com/v4test.html)
> It's really ancient. Consider upgrading to something not from stone
> age :) I doubt you'll be able to assemble anything generated by, for
> example, with mainline gcc.
>
> --
> 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
>



-- 
Juan Carlos Martínez Santos
242 Foster Drive Apt H
Colonial Townhouse Apartments
Willimantic, CT 06226-1538
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090618/ef75de25/attachment.html>

From deeppatel1987 at gmail.com  Thu Jun 18 14:56:17 2009
From: deeppatel1987 at gmail.com (Sandeep Patel)
Date: Thu, 18 Jun 2009 14:56:17 -0700
Subject: [LLVMdev] Unknown pseudo-op with -march=arm
In-Reply-To: <d17b77a40906181406x3c8672a0t9a5d4a061d81591f@mail.gmail.com>
References: <d17b77a40906181205i3a08f39fw65ad6c6b23365857@mail.gmail.com>
	<b087fca00906181230j6b65f569y6b7e6ec4a5076725@mail.gmail.com>
	<d17b77a40906181249p4a360d4re8c452b06357d84f@mail.gmail.com>
	<b087fca00906181326m67ba4d11xd932fdaa9222d480@mail.gmail.com>
	<d17b77a40906181406x3c8672a0t9a5d4a061d81591f@mail.gmail.com>
Message-ID: <305d6f60906181456j54758300u7d0ec8657dc7a41f@mail.gmail.com>

You need a newer binutils. That one is around eight years old. Try
binutils 2.19.1.

deep

On Thu, Jun 18, 2009 at 2:06 PM, Juan Carlos Martinez
Santos<juanc.martinez.santos at gmail.com> wrote:
> wow... Tell me, what cross compiler can I use for ARM if I am working in a
> i686-Linux machine? At the same time, how I can simulate it?
>
> But the way, If I deleted the unknown pseudo-op and change section .rodata
> definition, I can use my stone age cross compiler. I am just wondering why
> it works without them.
>
> Thanks in advance.
>
> On Thu, Jun 18, 2009 at 4:26 PM, Anton Korobeynikov
> <anton at korobeynikov.info> wrote:
>>
>> > I am using SimpleScalar cross-compiler 2.95.2
>> > (http://www.simplescalar.com/v4test.html)
>> It's really ancient. Consider upgrading to something not from stone
>> age :) I doubt you'll be able to assemble anything generated by, for
>> example, with mainline gcc.
>>
>> --
>> 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
>
>
>
> --
> Juan Carlos Martínez Santos
> 242 Foster Drive Apt H
> Colonial Townhouse Apartments
> Willimantic, CT 06226-1538
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>



From anton at korobeynikov.info  Thu Jun 18 15:18:17 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Fri, 19 Jun 2009 02:18:17 +0400
Subject: [LLVMdev] Unknown pseudo-op with -march=arm
In-Reply-To: <d17b77a40906181406x3c8672a0t9a5d4a061d81591f@mail.gmail.com>
References: <d17b77a40906181205i3a08f39fw65ad6c6b23365857@mail.gmail.com>
	<b087fca00906181230j6b65f569y6b7e6ec4a5076725@mail.gmail.com>
	<d17b77a40906181249p4a360d4re8c452b06357d84f@mail.gmail.com>
	<b087fca00906181326m67ba4d11xd932fdaa9222d480@mail.gmail.com>
	<d17b77a40906181406x3c8672a0t9a5d4a061d81591f@mail.gmail.com>
Message-ID: <b087fca00906181518r7317464em1ce1ebf5a5ef8068@mail.gmail.com>

> wow... Tell me, what cross compiler can I use for ARM if I am working in a i686-Linux machine?
As usual - gcc + binutils.

> At the same time, how I can simulate it?
QEMU ?

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


From julesjacobs at gmail.com  Thu Jun 18 15:57:54 2009
From: julesjacobs at gmail.com (Jules Jacobs)
Date: Fri, 19 Jun 2009 00:57:54 +0200
Subject: [LLVMdev] How to call C++ code from LLVM
Message-ID: <661d03540906181557q1a49e2d2g6ee355a77cde4832@mail.gmail.com>

Hi,
How can I call C++ libraries (LLVM & Qt for example) from a language that's
implemented on top of LLVM?

Thanks,
Jules
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090619/4621508b/attachment.html>

From eli.friedman at gmail.com  Thu Jun 18 17:19:02 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Thu, 18 Jun 2009 17:19:02 -0700
Subject: [LLVMdev] How to call C++ code from LLVM
In-Reply-To: <661d03540906181557q1a49e2d2g6ee355a77cde4832@mail.gmail.com>
References: <661d03540906181557q1a49e2d2g6ee355a77cde4832@mail.gmail.com>
Message-ID: <f5aa3e9b0906181719h102d52afxf7b0cddbfa1a852a@mail.gmail.com>

On Thu, Jun 18, 2009 at 3:57 PM, Jules Jacobs<julesjacobs at gmail.com> wrote:
> How can I call C++ libraries (LLVM & Qt for example) from a language that's
> implemented on top of LLVM?

You can call them the same way a C++ file compiled with llvm-g++ would
call them.  Essentially, it's complicated enough that you probably
don't want to do it for any interface of non-trivial size; I would
suggest compiling C++ snippets to bitcode with llvm-g++ and linking
them into your program.

For LLVM in particular, though, you can use the C bindings, which are
much more straightforward to use for this sort of thing.

-Eli


From vkutuzov at accesssoftek.com  Thu Jun 18 18:00:39 2009
From: vkutuzov at accesssoftek.com (Viktor Kutuzov)
Date: Thu, 18 Jun 2009 18:00:39 -0700
Subject: [LLVMdev] smul/smla td definitions
References: <d17b77a40906181205i3a08f39fw65ad6c6b23365857@mail.gmail.com><b087fca00906181230j6b65f569y6b7e6ec4a5076725@mail.gmail.com><d17b77a40906181249p4a360d4re8c452b06357d84f@mail.gmail.com><b087fca00906181326m67ba4d11xd932fdaa9222d480@mail.gmail.com><d17b77a40906181406x3c8672a0t9a5d4a061d81591f@mail.gmail.com>
	<b087fca00906181518r7317464em1ce1ebf5a5ef8068@mail.gmail.com>
Message-ID: <7F9B5DD273F64F73BDF894C73BE866DC@andreic6e7fe55>

Hi Anton,

Please find attached the td definitions for smul/smal.

Best regards,
Viktor
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smul_smla.td
Type: application/octet-stream
Size: 4583 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090618/5d7fde67/attachment.obj>

From eli.friedman at gmail.com  Thu Jun 18 21:50:15 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Thu, 18 Jun 2009 21:50:15 -0700
Subject: [LLVMdev] x86 Intel Syntax and MASM 9.x
In-Reply-To: <D79A8D1CEFA38E45AD075F6EB49D9E8C0D53F329@sefsexmb1.amd.com>
References: <D79A8D1CEFA38E45AD075F6EB49D9E8C0D53EFC6@sefsexmb1.amd.com>
	<f5aa3e9b0906151843g22b608a7u8397ee4854f17392@mail.gmail.com>
	<D79A8D1CEFA38E45AD075F6EB49D9E8C0D53F004@sefsexmb1.amd.com>
	<f5aa3e9b0906160009v37c61ca2q125522caf59b77df@mail.gmail.com>
	<D79A8D1CEFA38E45AD075F6EB49D9E8C0D53F2EF@sefsexmb1.amd.com>
	<f5aa3e9b0906161118j525c09c4o1a06a4e6b2a83e8@mail.gmail.com>
	<D79A8D1CEFA38E45AD075F6EB49D9E8C0D53F329@sefsexmb1.amd.com>
Message-ID: <f5aa3e9b0906182150o7dd729e7j41fbebe3a276dfbf@mail.gmail.com>

On Tue, Jun 16, 2009 at 12:18 PM, Gaster,
Benedict<Benedict.Gaster at amd.com> wrote:
> Sorry about that Visual Studio seems to have inserted tabs and I used an
> internal diff tool. Anyway, I synced TOT LLVM and made the changes with
> Emacs and the svn diff is attached.

Patch committed in r73753.

-Eli


From viridia at gmail.com  Thu Jun 18 23:15:20 2009
From: viridia at gmail.com (Talin)
Date: Thu, 18 Jun 2009 23:15:20 -0700
Subject: [LLVMdev] Garbage Collection Project
In-Reply-To: <200906180827.54686.jon@ffconsultancy.com>
References: <4A373DAC.9060807@gmail.com>
	<200906180827.54686.jon@ffconsultancy.com>
Message-ID: <4A3B2CF8.4000307@gmail.com>

Jon Harrop wrote:
> On Tuesday 16 June 2009 07:37:32 Talin wrote:
>   
>> A while back there was a discussion thread about whether an accurate,
>> concurrent garbage collector could be "generic" in the sense of being
>> able to support multiple different languages efficiently. After having
>> done some work on this, I now believe that this is the case - using C++
>> policy-based design principles, you can create a set of modules that
>> represent different aspects of collector behavior (such as
>> mark-and-sweep, stop-the-world, and so on) along with different aspects
>> of the runtime environment (object tracing strategies, heap structures,
>> threading primitives, atomics), and encode these various behaviors as
>> template classes which can be bound together to create an efficient
>> collector.
>>     
>
> Hi Talin,
>
> This is great news! I have some questions...
>   
And thank you for your interest! :)
> I had great success using some seemingly-unusual techniques in my experiments.
>
> Firstly, rather than using a single 1 word pointer to represent a reference I 
> chose to use 3 words including a pointer to the type and a pointer to the 
> value (as well as metadata). This allows typed nulls and that addresses an 
> important deficiency found in most other VMs including the CLR. Is Scarcity 
> able to handle such references or does its implementation of stack frames 
> require references to be a single word?
>   
As you no doubt know, there are a couple of different approaches to 
obtaining the type information for an object reference. These can be 
divided into static typing, where the compiler knows in advance the type 
of the reference, and object tagging, in which the type information is 
stored with the object being referred to (usually in the object itself, 
although your case its with the reference.)

Scarcity attempts to unify these two models by declaring that object 
tagging is a special case of static typing. For every object reference 
the compiler is required to supply a tracing strategy for that 
reference, in the form of a function that knows how to trace objects of 
that static type. That tracing strategy may know the entirety of the 
object's structure at compile time, in which case object tags are not 
needed; Or if the reference is polymorphic, then the tracing strategy 
function can inspect the object's tag in order to look up the metadata 
that describes where the references within the object are located. This 
is up to the language implementer to decide. In fact, you could 
conceivably have more than one object hierarchy each with it's own tag 
format, and so long as the compiler can determine statically which tag 
format is being used for a particular reference, it should all work.

The strategy function enumerates all of the references in the object and 
passes them to the trace visitor, which is a functor object supplied by 
the collection algorithm. The strategy function passes into the visitor 
a pointer to each reference, rather than the reference itself - the 
reason for this is to support copying collectors which can modify the 
reference to point to the new location.

This means that for your purposes, Scarcity does not dictate the format 
of object metadata nor the way objects are traced. However, some of the 
collector algorithms will assume that the pointer-to-reference is 
pointing to an object pointer. So you wouldn't be able to use those 
collector algorithms.

In other words, you probably won't be able to use the Scarcity 
collection algorithms for what you want, but what you can do is build a 
collector within the Scarcity framework that does what you want. Whether 
the various modules within Scarcity are valuable enough to be used in 
this way is up to you.
> Secondly, I used LLVM to JIT compile per-type code for garbage collection in 
> order to traverse data structures as efficiently as possible. Moreover, I 
> chose to write the entire GC in an unsafe subset of the language that I was 
> implementing so that I could rely upon tail calls and so forth. Does Scarcity 
> require the GC code to be written entirely in C?
>   
I imagine that most languages will want to write as much as possible in 
the hosted language rather than in C. The question is where to draw the 
dividing line. There are several issues which must be considered:

1) Small snippets of code such as write barriers should be inlined 
wherever possible. This pretty much requires that they be written in the 
same language as the code that they will be embedded within.

2) Many high-level languages really aren't very good at dealing with raw 
memory, because it requires you to introduce pointer arithmetic and 
other "unsafe" operations as you point out. For some languages, adding 
the necessary unsafe operations can distort and corrupt the language 
design to the point where it feels like you are writing a second 
compiler. If such is the case, then it makes sense to offload some of 
these operations to a lower-level language such as C.

3) In a hybrid approach where you are doing high-level stuff in your 
language, and then grunging around with pointers in C, there's some 
efficiency loss due to the fact that the compiler for each language 
cannot inline or optimize code written in the other language. (Although 
if you compile the C part with clang and use link-time optimization, you 
can mitigate that somewhat.) One has to think very carefully how to 
structure the API to avoid frequent jumping back and forth across the 
language barrier.

Because Scarcity is designed as a framework of modules, you can decide 
where to draw that line by deciding which modules that you are going to 
use. For example, you might choose not to use any of Scarcity's 
collection algorithms at all, but you still might use it's 
stop-the-world thread manager, or its memory heap.
> Finally, do you have any references describing the techniques you have used to 
> implement a concurrent GC? I have been reading up on the subject for several 
> years now, with a view to implementing my own concurrent GC.
>   
There's a wiki page on the scarcity site that lists references to a 
whole bunch of papers on garbage collection techniques.

   http://code.google.com/p/scarcity/wiki/RelevantPapers

-- Talin



From baldrick at free.fr  Fri Jun 19 01:31:47 2009
From: baldrick at free.fr (Duncan Sands)
Date: Fri, 19 Jun 2009 10:31:47 +0200
Subject: [LLVMdev] Explicitly Freeing Allocas
In-Reply-To: <24099580.post@talk.nabble.com>
References: <24093351.post@talk.nabble.com>
	<4A3A4BFD.6050603@cs.uiuc.edu>	<24094996.post@talk.nabble.com>	<549cee610906180815v7a39a0cg3c936e50f5145a51@mail.gmail.com>
	<24099580.post@talk.nabble.com>
Message-ID: <4A3B4CF3.1080109@free.fr>

Nyx wrote:
> I went ahead and implemented the allocation based on the maximum size of all
> structs seen so far... The problem is, the TargetData object from
> ExecutionEngine gives me a size of 12 for a struct containing a pointer and
> an i64 (on a 32-bit machine). However, the generated code seems to assume an
> alignment of 8, and tries to read the i64 value at offset 8, which obviously
> reads an invalid value.
> 
> Does the getSizeInBytes() method from StructLayout not take the alignment
> into account?

You should use getTypeAllocSize.  You can also get this without knowing
the target using ConstantExpr::getSizeOf.

Ciao,

Duncan.


From marks at dcs.gla.ac.uk  Fri Jun 19 02:01:44 2009
From: marks at dcs.gla.ac.uk (Mark Shannon)
Date: Fri, 19 Jun 2009 10:01:44 +0100
Subject: [LLVMdev] Undocumented API changes
In-Reply-To: <878wjqd2w6.fsf@telefonica.net>
References: <d17b77a40906170910h607175bcm6d51a23e0e11db6c@mail.gmail.com>	<4A391DCB.8070307@assumetheposition.nl>	<24361044-96E1-4490-A7B6-31A4E097CB46@apple.com>	<4A393EC4.80205@dcs.gla.ac.uk>	<63CDEC2F-D4A9-4E54-8372-5345D6DAA474@apple.com>
	<878wjqd2w6.fsf@telefonica.net>
Message-ID: <4A3B53F8.30408@dcs.gla.ac.uk>

Hi everyone,

Thanks for reading my rant, the other day ;)
All your comments were appreciated.

For llvm users (rather than developers) such as myself,
it seems that the best idea is to stick with the major releases.
I will stick with 2.5 until 2.6 arrives.

Has any thought been given to the possibility of bug-fix releases?

Cheers,
Mark.


From mcuelenaere at gmail.com  Fri Jun 19 03:58:42 2009
From: mcuelenaere at gmail.com (Maurus Cuelenaere)
Date: Fri, 19 Jun 2009 12:58:42 +0200
Subject: [LLVMdev] Compiler error when building LLVM-GCC
Message-ID: <4A3B6F62.7010509@gmail.com>

Hi all,

I'm not sure whether this is the right mailing list to post to (I didn't 
find any other related ones), but I'm having trouble compiling the GCC 
frontend for LLVM.

I can successfully compile LLVM using CMake, but am having compiler 
errors when doing LLVM-GCC:

/usr/bin/llvm-g++ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -pedantic 
-Wno-long-long -Wno-variadic-macros -Wmissing-format-attribute 
-fno-common -DHAVE_CONFIG_H -Wno-unused 
-DTARGET_NAME=\"i686-pc-linux-gnu\" -I. -I. -I../../../llvm-gcc/gcc 
-I../../../llvm-gcc/gcc/. -I../../../llvm-gcc/gcc/../include 
-I../../../llvm-gcc/gcc/../libcpp/include  
-I../../../llvm-gcc/gcc/../libdecnumber -I../libdecnumber 
-I/home/mcuelenaere/llvm_build/build_llvm-gcc/obj/../../build_llvm//include 
-I//include -DENABLE_LLVM 
-I/home/mcuelenaere/llvm_build/build_llvm/include   -D_GNU_SOURCE 
-D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS   -I. -I. 
-I../../../llvm-gcc/gcc -I../../../llvm-gcc/gcc/. 
-I../../../llvm-gcc/gcc/../include 
-I../../../llvm-gcc/gcc/../libcpp/include  
-I../../../llvm-gcc/gcc/../libdecnumber -I../libdecnumber 
-I/home/mcuelenaere/llvm_build/build_llvm-gcc/obj/../../build_llvm//include 
-I//include ../../../llvm-gcc/gcc/llvm-main.cpp -o llvm-main.o
../../../llvm-gcc/gcc/llvm-main.cpp:22:43: error: 
llvm/Support/PrettyStackTrace.h: No such file or directory
../../../llvm-gcc/gcc/llvm-main.cpp: In function 'int main(int, char**)':
../../../llvm-gcc/gcc/llvm-main.cpp:37: error: 'llvm' has not been declared
../../../llvm-gcc/gcc/llvm-main.cpp:37: error: expected `;' before 'X'

I configured with:

CC=/usr/bin/llvm-gcc CXX=/usr/bin/llvm-g++ ../../llvm-gcc/configure 
--prefix=`pwd`/../install --program-prefix=llvm- 
--enable-llvm=`pwd`/../../build_llvm/ --enable-languages=c,c++

This obviously sounds like something with the inclusion path not setup 
correctly, but --enable-lvm= contains the correct path so I'm not sure 
what causes this.

LLVM-GCC: SVN r73764
LLVM: SVN r73764

Regards,
Maurus Cuelenaere


From torvald at se.inf.tu-dresden.de  Fri Jun 19 08:14:27 2009
From: torvald at se.inf.tu-dresden.de (Torvald Riegel)
Date: Fri, 19 Jun 2009 17:14:27 +0200
Subject: [LLVMdev] Pool Allocation and DSA
In-Reply-To: <4A312D50.7040501@cs.uiuc.edu>
References: <4A2D8249.3090604@cs.uiuc.edu> <4A2FE031.1050702@cs.uiuc.edu>
	<4A312D50.7040501@cs.uiuc.edu>
Message-ID: <200906191714.27270.torvald@se.inf.tu-dresden.de>

On Thursday 11 June 2009 18:14:08 John Criswell wrote:
> If your use of pool allocation requires that you can always get the pool
> handle for a pointer, you need to make sure that pool allocation is
> configured so that it doesn't generate the above scenario.  I think
> there is an option to make all pools be global pools.

Some time ago, I used AnalysisUsage's addRequired<PoolAllocatePassAllPools>()  
to get this behavior. It didn't make all pools global.

Torvald


From clattner at apple.com  Fri Jun 19 08:40:11 2009
From: clattner at apple.com (Chris Lattner)
Date: Fri, 19 Jun 2009 08:40:11 -0700
Subject: [LLVMdev] Undocumented API changes
In-Reply-To: <4A3B53F8.30408@dcs.gla.ac.uk>
References: <d17b77a40906170910h607175bcm6d51a23e0e11db6c@mail.gmail.com>
	<4A391DCB.8070307@assumetheposition.nl>
	<24361044-96E1-4490-A7B6-31A4E097CB46@apple.com>
	<4A393EC4.80205@dcs.gla.ac.uk>
	<63CDEC2F-D4A9-4E54-8372-5345D6DAA474@apple.com>
	<878wjqd2w6.fsf@telefonica.net> <4A3B53F8.30408@dcs.gla.ac.uk>
Message-ID: <8EA60C9B-73E6-413F-BFA6-64C444245883@apple.com>


On Jun 19, 2009, at 2:01 AM, Mark Shannon wrote:

> Hi everyone,
>
> Thanks for reading my rant, the other day ;)
> All your comments were appreciated.
>
> For llvm users (rather than developers) such as myself,
> it seems that the best idea is to stick with the major releases.
> I will stick with 2.5 until 2.6 arrives.
>
> Has any thought been given to the possibility of bug-fix releases?

Yes, many people would like that, but we lack manpower to make extra  
releases happen.

-Chris


From simmon12 at cs.uiuc.edu  Fri Jun 19 09:23:12 2009
From: simmon12 at cs.uiuc.edu (Patrick Alexander Simmons)
Date: Fri, 19 Jun 2009 10:23:12 -0600
Subject: [LLVMdev] Pool Allocation and DSA (and: Re: DSA Question)
In-Reply-To: <200906191714.27270.torvald@se.inf.tu-dresden.de>
References: <4A2D8249.3090604@cs.uiuc.edu>
	<4A2FE031.1050702@cs.uiuc.edu>	<4A312D50.7040501@cs.uiuc.edu>
	<200906191714.27270.torvald@se.inf.tu-dresden.de>
Message-ID: <4A3BBB70.3070600@cs.uiuc.edu>

Torvald Riegel wrote:
> On Thursday 11 June 2009 18:14:08 John Criswell wrote:
>   
>> If your use of pool allocation requires that you can always get the pool
>> handle for a pointer, you need to make sure that pool allocation is
>> configured so that it doesn't generate the above scenario.  I think
>> there is an option to make all pools be global pools.
>>     
>
> Some time ago, I used AnalysisUsage's addRequired<PoolAllocatePassAllPools>()  
> to get this behavior. It didn't make all pools global.
>
> Torvald
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   

Okay, thanks, Torvald.  I assume this resulted in more pool descriptor 
arguments being passed; did you find this to hurt performance at all?

Once I have the local pool descriptor, it's occurred to me that what I 
basically need is the interprocedural use-def chain from a pool 
descriptor's Argument to the corresponding Values in the caller 
functions.  Unfortunately, I looked in the class hierarchy and found 
that Argument is not a subclass of User.  Still, perhaps someone has 
created an interprocedural def-use/use-def analysis pass for LLVM for 
some other purpose?

Thanks,
--Patrick


From sorokin at rain.ifmo.ru  Fri Jun 19 10:59:18 2009
From: sorokin at rain.ifmo.ru (=?windows-1251?B?yOLg7SDR7vDu6ujt?=)
Date: Fri, 19 Jun 2009 21:59:18 +0400
Subject: [LLVMdev] /lib/System/Atomic.cpp
Message-ID: <1951077627.20090619215918@rain.ifmo.ru>

Hello,

  Could you look at current implementation of
  AtomicIncrement/AtomicDecrement?

  I think there is a error in version for MSVC.

-- 
 Иван Сорокин                           mailto:sorokin at rain.ifmo.ru
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff
Type: application/octet-stream
Size: 827 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090619/20cb149f/attachment.obj>

From juanc.martinez.santos at gmail.com  Fri Jun 19 11:15:58 2009
From: juanc.martinez.santos at gmail.com (Juan Carlos Martinez Santos)
Date: Fri, 19 Jun 2009 14:15:58 -0400
Subject: [LLVMdev] Problems creating a pass
Message-ID: <d17b77a40906191115q6d93aadfj7f5d85d2e12cbcfe@mail.gmail.com>

Hello,

Following the tutorial for writing a pass, I found the next problem.

*****************************
:~/llvm/test$ opt -load ../llvm/Debug/lib/mypass.so -mypass < hello.bc >
/dev/null
opt: Pass.cpp:151: void<unnamed>::PassRegistrar::RegisterPass(const
llvm::PassInfo&): Assertion `Inserted && "Pass registered multiple times!"'
failed.
Aborted
*****************************

I just <copy> and then <paste> the code that appears in the web page, and
follow the instructions to run the pass. There is something missed,
something that is not in the web page [
http://llvm.org/docs/WritingAnLLVMPass.html#quickstart].

Thanks in advance.
-- 
Juan Carlos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090619/d1fd7cdc/attachment.html>

From sricketts at maxentric.com  Fri Jun 19 11:31:57 2009
From: sricketts at maxentric.com (Scott Ricketts)
Date: Fri, 19 Jun 2009 11:31:57 -0700
Subject: [LLVMdev] Problems creating a pass
In-Reply-To: <d17b77a40906191115q6d93aadfj7f5d85d2e12cbcfe@mail.gmail.com>
References: <d17b77a40906191115q6d93aadfj7f5d85d2e12cbcfe@mail.gmail.com>
Message-ID: <6d9073030906191131sd2a21c5p2b6445128c68f530@mail.gmail.com>

Did you try changing the name from Hello to MyHello or something like
that? I seem to remember having a similar problem. My tutorial code
names the struct MyHello and then registers it as follows:

RegisterPass<MyHello> X("myhello", "My Hello World Pass");

You will likely need to change the Makefile as well.

Scott

On Fri, Jun 19, 2009 at 11:15 AM, Juan Carlos Martinez
Santos<juanc.martinez.santos at gmail.com> wrote:
> Hello,
>
> Following the tutorial for writing a pass, I found the next problem.
>
> *****************************
> :~/llvm/test$ opt -load ../llvm/Debug/lib/mypass.so -mypass < hello.bc >
> /dev/null
> opt: Pass.cpp:151: void<unnamed>::PassRegistrar::RegisterPass(const
> llvm::PassInfo&): Assertion `Inserted && "Pass registered multiple times!"'
> failed.
> Aborted
> *****************************
>
> I just <copy> and then <paste> the code that appears in the web page, and
> follow the instructions to run the pass. There is something missed,
> something that is not in the web page
> [http://llvm.org/docs/WritingAnLLVMPass.html#quickstart].
>
> Thanks in advance.
> --
> Juan Carlos
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>



From resistor at mac.com  Fri Jun 19 11:43:22 2009
From: resistor at mac.com (Owen Anderson)
Date: Fri, 19 Jun 2009 11:43:22 -0700
Subject: [LLVMdev] /lib/System/Atomic.cpp
In-Reply-To: <1951077627.20090619215918@rain.ifmo.ru>
References: <1951077627.20090619215918@rain.ifmo.ru>
Message-ID: <C12E1712-63F6-498E-98C1-C7FFCBA6A1FF@mac.com>

Committed.  Thanks!

--Owen

On Jun 19, 2009, at 10:59 AM, Иван Сорокин wrote:

> Hello,
>
> Could you look at current implementation of
> AtomicIncrement/AtomicDecrement?
>
> I think there is a error in version for MSVC.
>
> -- Иван Сорокин                            
> mailto:sorokin 
> @rain.ifmo.ru<diff>_______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




From juanc.martinez.santos at gmail.com  Fri Jun 19 11:59:09 2009
From: juanc.martinez.santos at gmail.com (Juan Carlos Martinez Santos)
Date: Fri, 19 Jun 2009 14:59:09 -0400
Subject: [LLVMdev] Problems creating a pass
In-Reply-To: <6d9073030906191131sd2a21c5p2b6445128c68f530@mail.gmail.com>
References: <d17b77a40906191115q6d93aadfj7f5d85d2e12cbcfe@mail.gmail.com>
	<6d9073030906191131sd2a21c5p2b6445128c68f530@mail.gmail.com>
Message-ID: <d17b77a40906191159l5e958775h59cd5983e20b2151@mail.gmail.com>

Yes, I changed the names, tried another folder, change all the files
(file.cpp, Makefile, and CMakeList.txt) but still I get the same message.

Somebody has a clue?

Thanks,

Juan Carlos

On Fri, Jun 19, 2009 at 2:31 PM, Scott Ricketts <sricketts at maxentric.com>wrote:

> Did you try changing the name from Hello to MyHello or something like
> that? I seem to remember having a similar problem. My tutorial code
> names the struct MyHello and then registers it as follows:
>
> RegisterPass<MyHello> X("myhello", "My Hello World Pass");
>
> You will likely need to change the Makefile as well.
>
> Scott
>
> On Fri, Jun 19, 2009 at 11:15 AM, Juan Carlos Martinez
> Santos<juanc.martinez.santos at gmail.com> wrote:
> > Hello,
> >
> > Following the tutorial for writing a pass, I found the next problem.
> >
> > *****************************
> > :~/llvm/test$ opt -load ../llvm/Debug/lib/mypass.so -mypass < hello.bc >
> > /dev/null
> > opt: Pass.cpp:151: void<unnamed>::PassRegistrar::RegisterPass(const
> > llvm::PassInfo&): Assertion `Inserted && "Pass registered multiple
> times!"'
> > failed.
> > Aborted
> > *****************************
> >
> > I just <copy> and then <paste> the code that appears in the web page, and
> > follow the instructions to run the pass. There is something missed,
> > something that is not in the web page
> > [http://llvm.org/docs/WritingAnLLVMPass.html#quickstart].
> >
> > Thanks in advance.
> > --
> > Juan Carlos
> >
> > _______________________________________________
> > 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
>



-- 
Juan Carlos Martínez Santos
242 Foster Drive Apt H
Colonial Townhouse Apartments
Willimantic, CT 06226-1538
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090619/2df4130f/attachment.html>

From sricketts at maxentric.com  Fri Jun 19 14:06:56 2009
From: sricketts at maxentric.com (Scott Ricketts)
Date: Fri, 19 Jun 2009 14:06:56 -0700
Subject: [LLVMdev] Referring to an argument in another function
In-Reply-To: <4A3A9872.8020508@wxs.nl>
References: <6d9073030906181013n49ae169bu5ce9b1cc5d93cb74@mail.gmail.com>
	<4A3A9872.8020508@wxs.nl>
Message-ID: <6d9073030906191406p164b4168uf4f89863b824af23@mail.gmail.com>

On Thu, Jun 18, 2009 at 12:41 PM, Frits van Bommel<fvbommel at wxs.nl> wrote:
> You want to look at the operands of the call/invoke/free instruction, not the
> arguments of the function being called.
> So if you're sure it's a call or invoke (not a 'free' instruction), try
> something like this:
>
> #include "llvm/Support/CallSite.h"
> // ...
>         CallSite CS(&I);
>         CallSite::arg_iterator ait = CS.arg_begin(), aend = CS.arg_end();
>
>>       if (ait) {
>
> You want
>         if (ait != aend) {
> here.
>

Thanks!

CallSite is what I needed. I ended up getting P with CS.getArgument(0)
instead of an arg_iterator, but only because I first check that it is
an externally linked call to free with 1 argument.

Scott



From dag at cray.com  Fri Jun 19 14:32:37 2009
From: dag at cray.com (David Greene)
Date: Fri, 19 Jun 2009 16:32:37 -0500
Subject: [LLVMdev] Forward-declaring defs in TableGen
Message-ID: <200906191632.37692.dag@cray.com>

Is there a way to forward-declare a def in TableGen and then define it?

For example:

def foo : Foo;

def bar : Bar {
  let FooThing = foo;
}

def foo : Foo {
  let BarThing = bar;
}

This causes a multiple-definition error in TableGen.

                            -Dave


From lennart at augustsson.net  Fri Jun 19 16:31:33 2009
From: lennart at augustsson.net (Lennart Augustsson)
Date: Sat, 20 Jun 2009 00:31:33 +0100
Subject: [LLVMdev] Alloca and malloc alignment
Message-ID: <f4876cd70906191631l442d0e5dj6f413a18e2191c57@mail.gmail.com>

According to the LLVM manual, for both malloc and alloca:

  "If a constant alignment is specified, the value result of the
allocation is guaranteed to be aligned to at least that boundary. If
not specified, or if zero, the target can choose to align the
allocation on any convenient boundary."

I don't see the rationale for the second sentence, because it means
that alloca and malloc without an alignment are basically useless.
Why?  Because without a specified alignment the allocated memory might
not be properly aligned for the type that was specified.
It would be nice if the type argument to alloca&malloc were used to
determine a minimal acceptable alignment.

I discovered this by using alloca for a 2-element vector of i64, and
sure enough, the memory wasn't properly aligned and thus useless for
storing the vector (this was on i386).

  -- Lennart


From julesjacobs at gmail.com  Sat Jun 20 01:21:26 2009
From: julesjacobs at gmail.com (Jules Jacobs)
Date: Sat, 20 Jun 2009 10:21:26 +0200
Subject: [LLVMdev] How to call C++ code from LLVM
Message-ID: <661d03540906200121o4b1bb9cduc08660c75c6722bf@mail.gmail.com>

Hi,
How can I call C++ libraries (LLVM & Qt for example) from a language that's
implemented on top of LLVM?

Thanks,
Jules
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090620/b11de71a/attachment.html>

From fw at deneb.enyo.de  Sat Jun 20 02:15:08 2009
From: fw at deneb.enyo.de (Florian Weimer)
Date: Sat, 20 Jun 2009 11:15:08 +0200
Subject: [LLVMdev] Stack swapping
In-Reply-To: <162de7480906150605l44a594f5i5d5026e9d4b0fb73@mail.gmail.com>
	(Wesley W. Terpstra's message of "Mon, 15 Jun 2009 15:05:03 +0200")
References: <162de7480906150605l44a594f5i5d5026e9d4b0fb73@mail.gmail.com>
Message-ID: <878wjne06b.fsf@mid.deneb.enyo.de>

* Wesley W. Terpstra:

> I have a number of ideas on how to get this to work, but also assume
> that MLton isn't the first project which swaps stacks. What's the
> established best practice for managing multiple stacks under LLVM?

I think this isn't really a LLVM question.  For most platform ABIs,
LLVM code is compatible with stack switching because historically,
this was how multi-threading was implemented (and pthreads looks a lot
like stack switching, too), and there is quite a bit of software
around which does it (the PowerDNS recursor, Lua with the Coco patches
and LuaJIT).

The Coco patches for Lua have some discussion about portability and
implementation choices: <http://luajit.org/coco.html>


From baldrick at free.fr  Sat Jun 20 05:37:10 2009
From: baldrick at free.fr (Duncan Sands)
Date: Sat, 20 Jun 2009 14:37:10 +0200
Subject: [LLVMdev] Alloca and malloc alignment
In-Reply-To: <f4876cd70906191631l442d0e5dj6f413a18e2191c57@mail.gmail.com>
References: <f4876cd70906191631l442d0e5dj6f413a18e2191c57@mail.gmail.com>
Message-ID: <4A3CD7F6.9080007@free.fr>

Hi Lennart,

>   "If a constant alignment is specified, the value result of the
> allocation is guaranteed to be aligned to at least that boundary. If
> not specified, or if zero, the target can choose to align the
> allocation on any convenient boundary."
> 
> I don't see the rationale for the second sentence, because it means
> that alloca and malloc without an alignment are basically useless.
> Why?  Because without a specified alignment the allocated memory might
> not be properly aligned for the type that was specified.
> It would be nice if the type argument to alloca&malloc were used to
> determine a minimal acceptable alignment.

it is already used for that: if you supply an alignment of zero then it
uses the ABI alignment for the type.

> I discovered this by using alloca for a 2-element vector of i64, and
> sure enough, the memory wasn't properly aligned and thus useless for
> storing the vector (this was on i386).

Then that's a bug, please open a bug report with details.

Ciao,

Duncan.



From baldrick at free.fr  Sat Jun 20 06:38:34 2009
From: baldrick at free.fr (Duncan Sands)
Date: Sat, 20 Jun 2009 15:38:34 +0200
Subject: [LLVMdev] Compiler error when building LLVM-GCC
In-Reply-To: <4A3B6F62.7010509@gmail.com>
References: <4A3B6F62.7010509@gmail.com>
Message-ID: <4A3CE65A.2010801@free.fr>

Hi,

> CC=/usr/bin/llvm-gcc CXX=/usr/bin/llvm-g++ ../../llvm-gcc/configure 
> --prefix=`pwd`/../install --program-prefix=llvm- 
> --enable-llvm=`pwd`/../../build_llvm/ --enable-languages=c,c++

does it work if you compile using your system gcc/g++ rather than
with llvm-gcc/llvm-g++?

Ciao,

Duncan.


From fw at deneb.enyo.de  Sat Jun 20 06:50:44 2009
From: fw at deneb.enyo.de (Florian Weimer)
Date: Sat, 20 Jun 2009 15:50:44 +0200
Subject: [LLVMdev] unwind/invoke design
In-Reply-To: <162de7480906150946h549a0463k164017cb85c85ad0@mail.gmail.com>
	(Wesley W. Terpstra's message of "Mon, 15 Jun 2009 18:46:18 +0200")
References: <162de7480906150946h549a0463k164017cb85c85ad0@mail.gmail.com>
Message-ID: <87my838157.fsf@mid.deneb.enyo.de>

* Wesley W. Terpstra:

> The documentation of unwind/invoke is quite clear and does exactly
> what I need: unwinding the stack. I don't need it to carry an object
> back. I don't need it to figure out what the type of the object is or
> what catch() blocks it matches. I just need it to unwind the stack.

You can use your stack switching mechanism for this purpose.


From sorokin at rain.ifmo.ru  Sat Jun 20 06:55:57 2009
From: sorokin at rain.ifmo.ru (Ivan Sorokin)
Date: Sat, 20 Jun 2009 17:55:57 +0400
Subject: [LLVMdev] /include/llvm/Bitcode/BitstreamReader.h
Message-ID: <1762079838.20090620175557@rain.ifmo.ru>

Hello,

  I'm compiling LLVM with MSVC at the moment, I've got the following
  warning:

    BitstreamReader.h(327) : warning C4334: '<<' : result of 32-bit
    shift implicitly converted to 64 bits (was 64-bit shift intended?)

  in line

    uint64_t Piece = Read(NumBits);
    if ((Piece & (1U << (NumBits-1))) == 0)

  Is this warning relevant?

  Is also Read64() instead of Read() assumed?

-- 
 Ivan Sorokin                           mailto:sorokin at rain.ifmo.ru
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bitstream_reader.patch
Type: application/octet-stream
Size: 743 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090620/b93b2cbc/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bitstream_reader_ull_read64.patch
Type: application/octet-stream
Size: 863 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090620/b93b2cbc/attachment-0001.obj>

From pawelc6 at op.pl  Sat Jun 20 07:17:50 2009
From: pawelc6 at op.pl (pablogreen)
Date: Sat, 20 Jun 2009 07:17:50 -0700 (PDT)
Subject: [LLVMdev] How to call C++ code from LLVM
Message-ID: <24124138.post@talk.nabble.com>


Sorry could you help me? I have problem with using LLVM and some code in C
(.so file)
I want to use (simply example):

mylib.c:

#include <stdio.h>
void printString(char *str) {
    printf("%s", str);
}

mylib.h:

#ifndef MY_LIB_HEADER
#define MY_LIB_HEADER
void printString(char* X);
#endif
///////////////////////////////////////

Normally in C++ I do this: 
g++ -fPIC -c mylib.c          
g++ -shared -o libmylib.so mylib.o

(and after that :
 g++ -Wall -g -o prog.exe prog.c -I./ -lmylib -L./
 LD_LIBRARY_PATH=/home/mylinux/Desktop/test ./prog.exe)

My program I compile like this:
$ llvm-as -f prog.ll
$ llc -march=x86-64 prog.bc -f

but I have error after:
$ g++ -o prog prog.s -I./ -L./ -lmylib

/tmp/ccLAh0mg.o: In function `main':
asd.bc:(.text+0xd): undefined reference to `printString'
collect2: ld returned 1 exit status

in .bc file i have something like that:

; ModuleID = 'xyz'
internal constant [5 x i8] c"ello\00"		; <[5 x i8]*>:0 [#uses=1]

declare void @printInt(i32)

define i32 @main() {
entry:
	call void @printString(i8* getelementptr ([5 x i8]* @0, i32 0, i32 0))
	%tmpvar = alloca i32		; <i32*> [#uses=2]
	store i32 0, i32* %tmpvar
	%tmpvar1 = load i32* %tmpvar		; <i32> [#uses=1]
	ret i32 %tmpvar1
}
/////////////////////////////

Second possibility is try lli :working:
but when I try to:
LD_LIBRARY_PATH=/home/mylinux/Desktop/test lli prog.bc
i have:

ERROR: Program used external function 'printString' which could not be
resolved!
0   lli       0x00000000009efa43
1   libc.so.6 0x00007ff0f2ed5040
2   libc.so.6 0x00007ff0f2ed4fb5 gsignal + 53
3   libc.so.6 0x00007ff0f2ed6bc3 abort + 387
4   lli       0x000000000065f5c5
5   lli       0x000000000065fa6a
llvm::JIT::getPointerToFunction(llvm::Function*) + 362
6   lli       0x0000000000667248
7   lli       0x0000000000667474
8   lli       0x000000000066885d
9   lli       0x00000000004d8e4d
10  lli       0x000000000099fc3d
llvm::FPPassManager::runOnFunction(llvm::Function&) + 429
11  lli       0x00000000009a0016
llvm::FunctionPassManagerImpl::run(llvm::Function&) + 134
12  lli       0x00000000009a01cb
llvm::FunctionPassManager::run(llvm::Function&) + 75
13  lli       0x000000000065f6d8
llvm::JIT::runJITOnFunction(llvm::Function*) + 56
14  lli       0x000000000065fa19
llvm::JIT::getPointerToFunction(llvm::Function*) + 281
15  lli       0x00000000006609f4 llvm::JIT::runFunction(llvm::Function*,
std::vector<llvm::GenericValue, std::allocator<llvm::GenericValue> > const&)
+ 84
16  lli       0x000000000065c8aa
llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*,
std::vector<std::string, std::allocator<std::string> > const&, char const*
const*) + 1370
17  lli       0x00000000004d4d8f main + 671
18  libc.so.6 0x00007ff0f2ec05a6 __libc_start_main + 230
19  lli       0x00000000004d4399
Aborted
-- 
View this message in context: http://www.nabble.com/How-to-call-C%2B%2B-code-from-LLVM-tp24103450p24124138.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.



From felipe.lessa at gmail.com  Sat Jun 20 07:47:55 2009
From: felipe.lessa at gmail.com (Felipe Lessa)
Date: Sat, 20 Jun 2009 11:47:55 -0300
Subject: [LLVMdev] How to call C++ code from LLVM
In-Reply-To: <24124138.post@talk.nabble.com>
References: <24124138.post@talk.nabble.com>
Message-ID: <20090620144755.GA5393@kira.casa>

On Sat, Jun 20, 2009 at 07:17:50AM -0700, pablogreen wrote:
> Normally in C++ I do this:
> g++ -fPIC -c mylib.c
> g++ -shared -o libmylib.so mylib.o

Try compiling with GCC in C mode because C++ mangles the names
(e.g. to support overloading).

--
Felipe.


From mdevan.foobar at gmail.com  Sat Jun 20 08:21:30 2009
From: mdevan.foobar at gmail.com (Mahadevan R)
Date: Sat, 20 Jun 2009 20:51:30 +0530
Subject: [LLVMdev] Large aggregate types for function return types?
Message-ID: <c8033d570906200821p11e927a9ma7b27509b94a36cb@mail.gmail.com>

Hi all,

Are there any plans of supporting large aggregate types for function
return types in the near future? 2.6?

Thanks & Regards,
-Mahadevan.


From baldrick at free.fr  Sat Jun 20 09:46:05 2009
From: baldrick at free.fr (Duncan Sands)
Date: Sat, 20 Jun 2009 18:46:05 +0200
Subject: [LLVMdev] unwind/invoke design
In-Reply-To: <87my838157.fsf@mid.deneb.enyo.de>
References: <162de7480906150946h549a0463k164017cb85c85ad0@mail.gmail.com>
	<87my838157.fsf@mid.deneb.enyo.de>
Message-ID: <4A3D124D.6000907@free.fr>

Florian Weimer wrote:
> * Wesley W. Terpstra:
> 
>> The documentation of unwind/invoke is quite clear and does exactly
>> what I need: unwinding the stack. I don't need it to carry an object
>> back. I don't need it to figure out what the type of the object is or
>> what catch() blocks it matches. I just need it to unwind the stack.
> 
> You can use your stack switching mechanism for this purpose.

Or call libunwind directly.

Ciao,

Duncan.


From marks at dcs.gla.ac.uk  Sat Jun 20 09:56:55 2009
From: marks at dcs.gla.ac.uk (Mark Shannon)
Date: Sat, 20 Jun 2009 17:56:55 +0100
Subject: [LLVMdev] unwind/invoke design[MESSAGE NOT SCANNED]
In-Reply-To: <4A3D124D.6000907@free.fr>
References: <162de7480906150946h549a0463k164017cb85c85ad0@mail.gmail.com><87my838157.fsf@mid.deneb.enyo.de>
	<4A3D124D.6000907@free.fr>
Message-ID: <4A3D14D7.6080503@dcs.gla.ac.uk>

And don't forget good old setjmp/longjmp

Duncan Sands wrote:
> Florian Weimer wrote:
>> * Wesley W. Terpstra:
>>
>>> The documentation of unwind/invoke is quite clear and does exactly
>>> what I need: unwinding the stack. I don't need it to carry an object
>>> back. I don't need it to figure out what the type of the object is or
>>> what catch() blocks it matches. I just need it to unwind the stack.
>> You can use your stack switching mechanism for this purpose.
> 
> Or call libunwind directly.
> 
> 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 baldrick at free.fr  Sat Jun 20 09:58:43 2009
From: baldrick at free.fr (Duncan Sands)
Date: Sat, 20 Jun 2009 18:58:43 +0200
Subject: [LLVMdev] Large aggregate types for function return types?
In-Reply-To: <c8033d570906200821p11e927a9ma7b27509b94a36cb@mail.gmail.com>
References: <c8033d570906200821p11e927a9ma7b27509b94a36cb@mail.gmail.com>
Message-ID: <4A3D1543.4070602@free.fr>

Hi,

> Are there any plans of supporting large aggregate types for function
> return types in the near future? 2.6?

this is being tracked in
   http://llvm.org/PR2660
I don't know if anyone is working on it.

Ciao,

Duncan.


From pawelc6 at op.pl  Sat Jun 20 03:59:35 2009
From: pawelc6 at op.pl (pablogreen)
Date: Sat, 20 Jun 2009 03:59:35 -0700 (PDT)
Subject: [LLVMdev] How to call C++ code from LLVM
In-Reply-To: <f5aa3e9b0906181719h102d52afxf7b0cddbfa1a852a@mail.gmail.com>
References: <661d03540906181557q1a49e2d2g6ee355a77cde4832@mail.gmail.com>
	<f5aa3e9b0906181719h102d52afxf7b0cddbfa1a852a@mail.gmail.com>
Message-ID: <24124138.post@talk.nabble.com>


Sorry could you help me? I have problem with using LLVM and some code in C
(.so file)
I want to use (simply example):

mylib.c:

#include <stdio.h>
void printString(char *str) {
    printf("%s", str);
}

mylib.h:

#ifndef MY_LIB_HEADER
#define MY_LIB_HEADER
void printString(char* X);
#endif
///////////////////////////////////////

Normally in C++ I do this: 
g++ -fPIC -c mylib.c          
g++ -shared -o libmylib.so mylib.o

(and after that :
 g++ -Wall -g -o prog.exe prog.c -I./ -lmylib -L./
 LD_LIBRARY_PATH=/home/mylinux/Desktop/test ./prog.exe)

My program I compile like this:
$ llvm-as -f prog.ll
$ llc -march=x86-64 prog.bc -f

but I have error after:
$ g++ -o prog prog.s -I./ -L./ -lmylib

/tmp/ccLAh0mg.o: In function `main':
asd.bc:(.text+0xd): undefined reference to `printString'
collect2: ld returned 1 exit status

in .bc file i have something like that:

; ModuleID = 'xyz'
internal constant [5 x i8] c"ello\00"		; <[5 x i8]*>:0 [#uses=1]

declare void @printInt(i32)

define i32 @main() {
entry:
	call void @printString(i8* getelementptr ([5 x i8]* @0, i32 0, i32 0))
	%tmpvar = alloca i32		; <i32*> [#uses=2]
	store i32 0, i32* %tmpvar
	%tmpvar1 = load i32* %tmpvar		; <i32> [#uses=1]
	ret i32 %tmpvar1
}
/////////////////////////////

Second possibility is try lli :working:
but when I try to:
LD_LIBRARY_PATH=/home/mylinux/Desktop/test lli prog.bc
i have:

ERROR: Program used external function 'printString' which could not be
resolved!
0   lli       0x00000000009efa43
1   libc.so.6 0x00007ff0f2ed5040
2   libc.so.6 0x00007ff0f2ed4fb5 gsignal + 53
3   libc.so.6 0x00007ff0f2ed6bc3 abort + 387
4   lli       0x000000000065f5c5
5   lli       0x000000000065fa6a
llvm::JIT::getPointerToFunction(llvm::Function*) + 362
6   lli       0x0000000000667248
7   lli       0x0000000000667474
8   lli       0x000000000066885d
9   lli       0x00000000004d8e4d
10  lli       0x000000000099fc3d
llvm::FPPassManager::runOnFunction(llvm::Function&) + 429
11  lli       0x00000000009a0016
llvm::FunctionPassManagerImpl::run(llvm::Function&) + 134
12  lli       0x00000000009a01cb
llvm::FunctionPassManager::run(llvm::Function&) + 75
13  lli       0x000000000065f6d8
llvm::JIT::runJITOnFunction(llvm::Function*) + 56
14  lli       0x000000000065fa19
llvm::JIT::getPointerToFunction(llvm::Function*) + 281
15  lli       0x00000000006609f4 llvm::JIT::runFunction(llvm::Function*,
std::vector<llvm::GenericValue, std::allocator<llvm::GenericValue> > const&)
+ 84
16  lli       0x000000000065c8aa
llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*,
std::vector<std::string, std::allocator<std::string> > const&, char const*
const*) + 1370
17  lli       0x00000000004d4d8f main + 671
18  libc.so.6 0x00007ff0f2ec05a6 __libc_start_main + 230
19  lli       0x00000000004d4399
Aborted
-- 
View this message in context: http://www.nabble.com/How-to-call-C%2B%2B-code-from-LLVM-tp24103450p24124138.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.



From pawelc6 at op.pl  Sat Jun 20 12:12:08 2009
From: pawelc6 at op.pl (pablogreen)
Date: Sat, 20 Jun 2009 12:12:08 -0700 (PDT)
Subject: [LLVMdev] How to call C++ code from LLVM
In-Reply-To: <20090620144755.GA5393@kira.casa>
References: <661d03540906181557q1a49e2d2g6ee355a77cde4832@mail.gmail.com>
	<f5aa3e9b0906181719h102d52afxf7b0cddbfa1a852a@mail.gmail.com>
	<24124138.post@talk.nabble.com> <20090620144755.GA5393@kira.casa>
Message-ID: <24128342.post@talk.nabble.com>


Thanks :jumping:
-- 
View this message in context: http://www.nabble.com/How-to-call-C%2B%2B-code-from-LLVM-tp24103450p24128342.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.



From clattner at apple.com  Sat Jun 20 19:30:16 2009
From: clattner at apple.com (Chris Lattner)
Date: Sat, 20 Jun 2009 19:30:16 -0700
Subject: [LLVMdev] proposal to simplify isel/asmprinter interaction with
	globals
Message-ID: <5E343D57-E3E2-4C45-B3B1-952D90AC5ACF@apple.com>

Hi All,

I'm working on various cleanups and simplifications to the  
asmprinters.  One thing that is driving me nuts is that the  
asmprinters currently "reverse engineer" a lot of information when  
printing an operand that isel had when it created it.

I'm specifically talking about all the suffixes generated by isel,  
like $non_lazy_ptr, @TLSGD, @NTPOFF, (%rip) etc.  These are all  
"magic" things that the assembler uses (for example, it generates a  
reference to a global's GOT entry instead of to the global itself).

The thing that is really frustrating to me is that the asmprinters  
need to reverse engineer what isel *meant* in order to output the  
right thing.  For example, to determine whether to emit $non_lazy_ptr,  
it uses a logic tree like this:

     if (shouldPrintStub(TM, Subtarget)) {
       // Link-once, declaration, or Weakly-linked global variables need
       // non-lazily-resolved stubs
       if (GV->isDeclaration() || GV->isWeakForLinker()) {
         // Dynamically-resolved functions need a stub for the function.
         if (GV->hasHiddenVisibility()) {
           if (!GV->isDeclaration() && !GV->hasCommonLinkage())
   ...
           else {
             printSuffixedName(Name, "$non_lazy_ptr");
           }
         } else {
           printSuffixedName(Name, "$non_lazy_ptr");
         }

  where shouldPrintStub is:

static inline bool shouldPrintStub(TargetMachine &TM, const  
X86Subtarget* ST) {
   return ST->isPICStyleStub() && TM.getRelocationModel() !=  
Reloc::Static;
}

This is really redundant with isel, because isel also needs to know  
exactly which GV references go through a stub so that it isels the  
access correctly.

My proposed fix for this is to add an 'unsigned char' slot to  
MachineOperand that holds a target-specific enum value.  The code in  
asmprinter would be reduced to:

switch (theoperandenum) {
case X86::MO_Flag_non_lazy_ptr:
   O << "$non_lazy_ptr";
   break;
case X86::MO_Flag_TLSGD:
   O << "@TLSGD";
   break;
case X86::MO_Flag_NTPOFF:
   O << "@NTPOFF";
   break;


etc.  The possible set of suffixes and modifiers are all target- 
specific, so the main code generator would just pass them through (as  
it does now).

Does anyone have any objections to this?

-Chris


From anton at korobeynikov.info  Sat Jun 20 21:51:53 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Sun, 21 Jun 2009 08:51:53 +0400
Subject: [LLVMdev] proposal to simplify isel/asmprinter interaction with
	globals
In-Reply-To: <5E343D57-E3E2-4C45-B3B1-952D90AC5ACF@apple.com>
References: <5E343D57-E3E2-4C45-B3B1-952D90AC5ACF@apple.com>
Message-ID: <b087fca00906202151x5af17b3eo19123edb12b7f905@mail.gmail.com>

Hi, Chris

> Does anyone have any objections to this?
Sounds good. I also thought about this as a part of the whole program
to refactor asm emission logic. Unfortunately I had no time to
implement this by myself :(

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


From torvald at se.inf.tu-dresden.de  Sun Jun 21 03:53:19 2009
From: torvald at se.inf.tu-dresden.de (Torvald Riegel)
Date: Sun, 21 Jun 2009 12:53:19 +0200
Subject: [LLVMdev] Pool Allocation and DSA (and: Re: DSA Question)
In-Reply-To: <4A3BBB70.3070600@cs.uiuc.edu>
References: <4A2D8249.3090604@cs.uiuc.edu>
	<200906191714.27270.torvald@se.inf.tu-dresden.de>
	<4A3BBB70.3070600@cs.uiuc.edu>
Message-ID: <200906211253.21535.torvald@se.inf.tu-dresden.de>

On Friday 19 June 2009 18:23:12 Patrick Alexander Simmons wrote:
> Torvald Riegel wrote:
> > On Thursday 11 June 2009 18:14:08 John Criswell wrote:
> >> If your use of pool allocation requires that you can always get the pool
> >> handle for a pointer, you need to make sure that pool allocation is
> >> configured so that it doesn't generate the above scenario.  I think
> >> there is an option to make all pools be global pools.
> >
> > Some time ago, I used AnalysisUsage's
> > addRequired<PoolAllocatePassAllPools>() to get this behavior. It didn't
> > make all pools global.
> >
> > Torvald
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> Okay, thanks, Torvald.  I assume this resulted in more pool descriptor
> arguments being passed; did you find this to hurt performance at all?

I needed all of them, so I didn't check whether it hurt performance. It will 
also depend a lot on your target applications. PoolAlloc has some statistics 
for the maximum number of pools per function IIRC.

> Once I have the local pool descriptor, it's occurred to me that what I
> basically need is the interprocedural use-def chain from a pool
> descriptor's Argument to the corresponding Values in the caller
> functions.  Unfortunately, I looked in the class hierarchy and found
> that Argument is not a subclass of User.  Still, perhaps someone has
> created an interprocedural def-use/use-def analysis pass for LLVM for
> some other purpose?

The call sites (call and invoke instrs) are the users of the functions and 
supply the arguments. Several different pool instances might get passed to a 
function. Top-Down and Bottom-Up DSA find these sets to some extend (in order 
to unify the DS nodes and pools), but I think none of them guarantees to find a 
complete unification. I guess looking at Bottom-Up DSA's code should be 
helpful.

Torvald


From jon at ffconsultancy.com  Sun Jun 21 14:51:05 2009
From: jon at ffconsultancy.com (Jon Harrop)
Date: Sun, 21 Jun 2009 22:51:05 +0100
Subject: [LLVMdev] SSE examples
Message-ID: <200906212251.05364.jon@ffconsultancy.com>


Does anyone have any LLVM IR examples implementing things using the 
instructions for SSE, like complex arithmetic or 3D vector-matrix stuff?

I'd like to have HLVM use them "under the hood" for some things but I cannot 
see all of the operations that I was expecting (e.g. dot product) and am not 
sure what works when (e.g. "Not all targets support all types however.").

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e


From jyasskin at google.com  Sun Jun 21 22:49:08 2009
From: jyasskin at google.com (Jeffrey Yasskin)
Date: Sun, 21 Jun 2009 22:49:08 -0700
Subject: [LLVMdev] Adding safe-point code generation
Message-ID: <bb55930e0906212249k6dd406b4x514867cc2d02086c@mail.gmail.com>

Hi all,

I need to add thread-switching support to Unladen Swallow's JIT, and
LLVM's safe point support looks like a good way to get code into all
the right places. However,
http://llvm.org/docs/GarbageCollection.html#collector-algos points out
that there's no way to emit code at safe points yet, and there are no
loop safe points at all. So I'll be trying to implement them.

Is there anything I should know before starting?

One way to do this might be to add a FunctionPass to
LLVMTargetMachine::addCommonCodeGenPasses() alongside
createGCLoweringPass(), which would insert user-defined code for safe
points. Unfortunately, code inserted there would stick around in the
IR after the machine code was emitted, and if the function were JITted
again, we'd get duplicate safe points.

Another way to do it might be to add a MachineFunction pass next to
createGCMachineCodeAnalysisPass() (or instead of it), which could emit
appropriate MachineInstructions to implement the safe point. This, of
course, forces safe points to be written in MachineInstructions
instead of IR instructions, which isn't ideal.

Another way might be to run a pass over the IR inserting
llvm.safepoint() calls, which could be implemented as a function in
the module. Then we'd want a MachineFunction pass to inline this for
us during codegen. The llvm.safepoint() calls could be easily
identified and removed if the IR needs to be re-used.

Thoughts?

Thanks,
Jeffrey


From gil.dogon at mobileye.com  Mon Jun 22 00:35:57 2009
From: gil.dogon at mobileye.com (Gil Dogon)
Date: Mon, 22 Jun 2009 10:35:57 +0300
Subject: [LLVMdev] A question about backend implementation of instructions
 with special register allocation needs.
Message-ID: <4A3F345D.1060003@mobileye.com>

I stumbled upon the following problem when truing to support the 
following non-standard  instruction extensions to a MIPS like architecture:

1.)
    double store :   Ri,Ri+1  are stored to the memory at address 
specified by (Rj).
    Here the instruction encoding includes only  'i' but it implicitly 
uses also Ri+1.   I can define a special intrinsic for this in "C"
   such as store64(int v1,int v2,int *address), but then I run into 
problems with the register allocation as I need to tell it that
   I want to use Ri and Ri+1 an not just any general pair of registers ....
2.) Just  any kind of instruction with register update semantics. like  
for simplicity sake suppose I have  an instruction such as
      which updates Ri , such as    Ri  <-  somefunc(Ri,Rj).
     can I specify the same argument as both input and output in the 
tablegen instrinfo.td and just hope it works ?

My general question, is if there is some general  way to tell the 
register allocator about constraints when choosing the registers
it allocates because of the requirements of some instructions....


From nicolas.geoffray at lip6.fr  Mon Jun 22 00:57:35 2009
From: nicolas.geoffray at lip6.fr (Nicolas Geoffray)
Date: Mon, 22 Jun 2009 09:57:35 +0200
Subject: [LLVMdev] Adding safe-point code generation
In-Reply-To: <bb55930e0906212249k6dd406b4x514867cc2d02086c@mail.gmail.com>
References: <bb55930e0906212249k6dd406b4x514867cc2d02086c@mail.gmail.com>
Message-ID: <4A3F396F.8040103@lip6.fr>

Hi Jeffrey,

Jeffrey Yasskin wrote:
> Hi all,
>
> I need to add thread-switching support to Unladen Swallow's JIT, and
> LLVM's safe point support looks like a good way to get code into all
> the right places. However,
> http://llvm.org/docs/GarbageCollection.html#collector-algos points out
> that there's no way to emit code at safe points yet, and there are no
> loop safe points at all. So I'll be trying to implement them.
>
>   

That's great!

> Is there anything I should know before starting?
>
> One way to do this might be to add a FunctionPass to
> LLVMTargetMachine::addCommonCodeGenPasses() alongside
> createGCLoweringPass(), which would insert user-defined code for safe
> points. Unfortunately, code inserted there would stick around in the
> IR after the machine code was emitted, and if the function were JITted
> again, we'd get duplicate safe points.
>
>   

Agree. I guess, a flag on a function saying that GC/Thread points have 
already been inserted would make it.

> Another way to do it might be to add a MachineFunction pass next to
> createGCMachineCodeAnalysisPass() (or instead of it), which could emit
> appropriate MachineInstructions to implement the safe point. This, of
> course, forces safe points to be written in MachineInstructions
> instead of IR instructions, which isn't ideal.
>
>   

I don't think that's worth the pain, if it's only to avoid duplicated 
safe points.

> Another way might be to run a pass over the IR inserting
> llvm.safepoint() calls, which could be implemented as a function in
> the module. Then we'd want a MachineFunction pass to inline this for
> us during codegen. The llvm.safepoint() calls could be easily
> identified and removed if the IR needs to be re-used.
>
>   

I like this one. I think that's the best way to go. The safe points 
"pass" in the GC already computes the safe points (except for "for 
loops") , so we've got a base. I don't think llvm.safepoint needs to be 
a function, a function pass could replace the intrinsic with instructions.

Thanks for working on this!

Nicolas

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



From anton at korobeynikov.info  Mon Jun 22 01:43:19 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Mon, 22 Jun 2009 12:43:19 +0400
Subject: [LLVMdev] A question about backend implementation of
	instructions with special register allocation needs.
In-Reply-To: <4A3F345D.1060003@mobileye.com>
References: <4A3F345D.1060003@mobileye.com>
Message-ID: <b087fca00906220143o4da09216h1a4da51cb9a00093@mail.gmail.com>

Hello, Gil

>    double store :   Ri,Ri+1  are stored to the memory at address
> specified by (Rj).
Why don't define new register class for such sort of things with wide
"virtual" registers containing Ri,Ri+1 as subregs? You can emit such
wide stores and even do some post-pass to convert narrow stores into
wide one (look into ARM's multiple store pass). Recently added
regalloc hints will even help regalloc to generate narrow stores which
can be turned into wide later.

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


From Sachin.Punyani at microchip.com  Mon Jun 22 03:56:43 2009
From: Sachin.Punyani at microchip.com (Sachin.Punyani at microchip.com)
Date: Mon, 22 Jun 2009 03:56:43 -0700
Subject: [LLVMdev] Floating point comparison doubt
Message-ID: <F536B7C316F9474E9F7091239725AC9A02B1170B@CHN-CL-MAIL01.mchp-main.com>

Hi,

 

In unordered floating point comparison before making a call for
comparison proper one node called UO_F32 is generated. In targets this
node is replaced with a call to __unordsf2.

 

My doubts here

1)  What are these UO_F32 and O_F32 nodes for?

2)  What is this function (__unordsf2) supposed to do?

 

Regards

Sachin

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090622/51812e27/attachment.html>

From public at alisdairm.net  Mon Jun 22 05:11:21 2009
From: public at alisdairm.net (AlisdairM(public))
Date: Mon, 22 Jun 2009 13:11:21 +0100
Subject: [LLVMdev] waiting for bugzilla password
Message-ID: <01a601c9f332$8ebdfd60$ac39f820$@net>

I have tried to create a bugzilla account from this email address (public at alisdairm.net) to report issues with Clang, but have been waiting for my password for around 48 hours.  The create-account page suggests emailing this address if there is a problem, so...

HELP!!!!

Thanks ;¬)

AlisdairM





From cr88192 at hotmail.com  Mon Jun 22 08:37:41 2009
From: cr88192 at hotmail.com (BGB)
Date: Mon, 22 Jun 2009 08:37:41 -0700
Subject: [LLVMdev] SSE examples
References: <200906212251.05364.jon@ffconsultancy.com>
Message-ID: <BLU0-SMTP100ADB2CD5A5DBE4605E851E4390@phx.gbl>


----- Original Message ----- 
From: "Jon Harrop" <jon at ffconsultancy.com>
To: <llvmdev at cs.uiuc.edu>
Sent: Sunday, June 21, 2009 2:51 PM
Subject: [LLVMdev] SSE examples


>
> Does anyone have any LLVM IR examples implementing things using the
> instructions for SSE, like complex arithmetic or 3D vector-matrix stuff?
>

I don't have any examples...


> I'd like to have HLVM use them "under the hood" for some things but I 
> cannot
> see all of the operations that I was expecting (e.g. dot product) and am 
> not
> sure what works when (e.g. "Not all targets support all types however.").
>

LLVM is probably implementing actual SSE, and not a wrapped/extended form.
it can be noted that, apart from some very new SSE variants (aka: very new 
CPUs), operations like dot-product don't exist, and so would have to be 
simulated (for example, by serializing the values to the stack and running 
them through the FPU or similar...).

so, in general, if one wants specific vectors (such as geometric vectors, 
quaternions, ...), one usually has to implement them in terms of the 
existing matrix operations.


I don't know what the best way to deal with this in LLVM would be, someone 
else may have a better idea.


as for what targets support which operations, in the case of SSE, go check 
the Intel and AMD64 docs.
it can be noted that most processors around now support SSE2, but not as 
many support newer (SSE3/SSSE3, SSE4, ...).

note that Intel and AMD have had a split over the issue:
Intel implements SSE3 and SSE4;
AMD implements parts of SSE3 and SSE4, but not other parts;
AMD is implementing SSE5, but it uses instructions which Intel does not use;
...

so, SSE2 is fairly safe at this point, but much newer is an area with some 
peril...

it would require checking documentation to know which operations are part of 
which subset.


granted though, going too far down this route (especially if LLVM does not 
fake ops on targets where they don't exist), is a route likely to somewhat 
hurt the "generic portability" of code.

(in my case, I only target x86 and x86-64, and at present restrict myself 
mostly to SSE2).


> -- 
> Dr Jon Harrop, Flying Frog Consultancy Ltd.
> http://www.ffconsultancy.com/?e
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 



From tonic at nondot.org  Mon Jun 22 11:08:19 2009
From: tonic at nondot.org (Tanya M. Lattner)
Date: Mon, 22 Jun 2009 11:08:19 -0700 (PDT)
Subject: [LLVMdev] waiting for bugzilla password
In-Reply-To: <01a601c9f332$8ebdfd60$ac39f820$@net>
References: <01a601c9f332$8ebdfd60$ac39f820$@net>
Message-ID: <alpine.DEB.2.00.0906221104160.27637@nondot.org>


> I have tried to create a bugzilla account from this email address 
> (public at alisdairm.net) to report issues with Clang, but have been 
> waiting for my password for around 48 hours.  The create-account page 
> suggests emailing this address if there is a problem, so...
>
> HELP!!!!

I'm sorry, there was a problem on the llvm.org server. I believe it should 
be fixed now. Please try to create your account again and if you have 
problems, feel free to email me directly offlist.

Thanks,
Tanya

>
> Thanks ;¬)
>
> AlisdairM
>
>
>
> _______________________________________________
> 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  Mon Jun 22 11:49:07 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Mon, 22 Jun 2009 11:49:07 -0700
Subject: [LLVMdev] proposal to simplify isel/asmprinter interaction
	with	globals
In-Reply-To: <5E343D57-E3E2-4C45-B3B1-952D90AC5ACF@apple.com>
References: <5E343D57-E3E2-4C45-B3B1-952D90AC5ACF@apple.com>
Message-ID: <E856BD4F-73E5-4E32-9118-A9E4A73DEB72@apple.com>


On Jun 20, 2009, at 7:30 PM, Chris Lattner wrote:

>
>
> My proposed fix for this is to add an 'unsigned char' slot to
> MachineOperand that holds a target-specific enum value.  The code in
> asmprinter would be reduced to:
>
> switch (theoperandenum) {
> case X86::MO_Flag_non_lazy_ptr:
>   O << "$non_lazy_ptr";
>   break;
> case X86::MO_Flag_TLSGD:
>   O << "@TLSGD";
>   break;
> case X86::MO_Flag_NTPOFF:
>   O << "@NTPOFF";
>   break;
>
>
> etc.  The possible set of suffixes and modifiers are all target-
> specific, so the main code generator would just pass them through (as
> it does now).
>
> Does anyone have any objections to this?

Can you reorg MachineOperand fields while you are at it? :-) Right now  
each MachineOperand uses 8 bits for type, followed by 5 bits for  
various flags, then a whole 8-bit for subreg.  If we use just 3-bit  
for subreg (should be enough?), the target independent part will just  
take up 16-bits and leave plenty of room for target flags.

Evan

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



From jon at ffconsultancy.com  Mon Jun 22 13:54:24 2009
From: jon at ffconsultancy.com (Jon Harrop)
Date: Mon, 22 Jun 2009 21:54:24 +0100
Subject: [LLVMdev] SSE examples
In-Reply-To: <BLU0-SMTP100ADB2CD5A5DBE4605E851E4390@phx.gbl>
References: <200906212251.05364.jon@ffconsultancy.com>
	<BLU0-SMTP100ADB2CD5A5DBE4605E851E4390@phx.gbl>
Message-ID: <200906222154.24376.jon@ffconsultancy.com>

On Monday 22 June 2009 16:37:41 BGB wrote:
> as for what targets support which operations, in the case of SSE, go check
> the Intel and AMD64 docs.

I was assuming that LLVM's implementations were incomplete. Are they now 
complete? So anything that a CPU can do and LLVM has bindings for is 
implemented?

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e


From aaronngray.lists at googlemail.com  Mon Jun 22 13:01:16 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Mon, 22 Jun 2009 21:01:16 +0100
Subject: [LLVMdev] Getting Circular dependancy between
	libLLVMAlphaAsmPrinter.a and libLLVMAlphaCodeGen.a
Message-ID: <9719867c0906221301i56790596p6ef9582f5ac7f8d4@mail.gmail.com>

Hi,

I am getting the following error message :-

llvm[1]: Checking for cyclic dependencies between LLVM libraries.
find-cycles.pl: Circular dependency between *.a files:
find-cycles.pl:   libLLVMAlphaAsmPrinter.a libLLVMAlphaCodeGen.a
llvm[1]: Building llvm-config script.
cat: /home/ang/build/dev/tools/llvm-config/FinalLibDeps.txt: No such file or
directory
make[1]: *** [/home/ang/build/dev/Debug/bin/llvm-config] Error 1
make[1]: Leaving directory `/home/ang/build/dev/tools/llvm-config'
make: *** [all] Error 1
Thanks,

Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090622/40e80a5e/attachment.html>

From anton at korobeynikov.info  Mon Jun 22 13:25:02 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Tue, 23 Jun 2009 00:25:02 +0400
Subject: [LLVMdev] Getting Circular dependancy between
	libLLVMAlphaAsmPrinter.a and libLLVMAlphaCodeGen.a
In-Reply-To: <9719867c0906221301i56790596p6ef9582f5ac7f8d4@mail.gmail.com>
References: <9719867c0906221301i56790596p6ef9582f5ac7f8d4@mail.gmail.com>
Message-ID: <b087fca00906221325v739492edu42bd8af4cb2aded7@mail.gmail.com>

> I am getting the following error message :-
Try to update to TOT. The problem was fixed ~3 days ago.

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


From kasra_n500 at yahoo.com  Mon Jun 22 14:19:49 2009
From: kasra_n500 at yahoo.com (Kasra)
Date: Mon, 22 Jun 2009 14:19:49 -0700 (PDT)
Subject: [LLVMdev] X86 JIT
Message-ID: <815322.86897.qm@web110002.mail.gq1.yahoo.com>

Hi,

for some reason I could not get the machine code generator for x86 working. The interpreter is the only thing that works, is there anything that I am missing here?

-- Kasra


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090622/89dca208/attachment.html>

From aaronngray.lists at googlemail.com  Mon Jun 22 14:23:48 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Mon, 22 Jun 2009 22:23:48 +0100
Subject: [LLVMdev] Getting Circular dependancy between
	libLLVMAlphaAsmPrinter.a and libLLVMAlphaCodeGen.a
In-Reply-To: <b087fca00906221325v739492edu42bd8af4cb2aded7@mail.gmail.com>
References: <9719867c0906221301i56790596p6ef9582f5ac7f8d4@mail.gmail.com> 
	<b087fca00906221325v739492edu42bd8af4cb2aded7@mail.gmail.com>
Message-ID: <9719867c0906221423i71b157b8xd25cd04c0c881fe0@mail.gmail.com>

No its still there I have done clean SVN checkouts, both on Linux and on
Cygwin and am getting the same results.

Aaron

2009/6/22 Anton Korobeynikov <anton at korobeynikov.info>

> > I am getting the following error message :-
> Try to update to TOT. The problem was fixed ~3 days ago.
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090622/8839c44c/attachment.html>

From cr88192 at hotmail.com  Mon Jun 22 14:55:04 2009
From: cr88192 at hotmail.com (BGB)
Date: Mon, 22 Jun 2009 14:55:04 -0700
Subject: [LLVMdev] SSE examples
References: <200906212251.05364.jon@ffconsultancy.com><BLU0-SMTP100ADB2CD5A5DBE4605E851E4390@phx.gbl>
	<200906222154.24376.jon@ffconsultancy.com>
Message-ID: <BLU0-SMTP917B7F25537A609B53D3CE4390@phx.gbl>


----- Original Message ----- 
From: "Jon Harrop" <jon at ffconsultancy.com>
To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
Sent: Monday, June 22, 2009 1:54 PM
Subject: Re: [LLVMdev] SSE examples


> On Monday 22 June 2009 16:37:41 BGB wrote:
>> as for what targets support which operations, in the case of SSE, go 
>> check
>> the Intel and AMD64 docs.
>
> I was assuming that LLVM's implementations were incomplete. Are they now
> complete? So anything that a CPU can do and LLVM has bindings for is
> implemented?
>

I don't know as much about LLVM specifically, someone else can probably 
provide a better answer...


but, if you are meaning for things like dot product intrinsics, it is worth 
noting that these are not part of SSE or SSE2.


actually, dot product was added for SSE4.1, so it is only likely to be found 
in Intel CPUs starting from late 2008 / early 2009...

as such, I would not advise depending on it just yet...


> -- 
> Dr Jon Harrop, Flying Frog Consultancy Ltd.
> http://www.ffconsultancy.com/?e
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 



From aaronngray.lists at googlemail.com  Mon Jun 22 14:55:36 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Mon, 22 Jun 2009 22:55:36 +0100
Subject: [LLVMdev] Getting Circular dependancy between
	libLLVMAlphaAsmPrinter.a and libLLVMAlphaCodeGen.a
In-Reply-To: <b087fca00906221325v739492edu42bd8af4cb2aded7@mail.gmail.com>
References: <9719867c0906221301i56790596p6ef9582f5ac7f8d4@mail.gmail.com> 
	<b087fca00906221325v739492edu42bd8af4cb2aded7@mail.gmail.com>
Message-ID: <9719867c0906221455ybc03690n1533f83298217098@mail.gmail.com>

Still not working, what does TOT stand for ?

2009/6/22 Anton Korobeynikov <anton at korobeynikov.info>

> > I am getting the following error message :-
> Try to update to TOT. The problem was fixed ~3 days ago.
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090622/3e7fe767/attachment.html>

From anton at korobeynikov.info  Mon Jun 22 15:22:27 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Tue, 23 Jun 2009 02:22:27 +0400
Subject: [LLVMdev] Getting Circular dependancy between
	libLLVMAlphaAsmPrinter.a and libLLVMAlphaCodeGen.a
In-Reply-To: <9719867c0906221455ybc03690n1533f83298217098@mail.gmail.com>
References: <9719867c0906221301i56790596p6ef9582f5ac7f8d4@mail.gmail.com>
	<b087fca00906221325v739492edu42bd8af4cb2aded7@mail.gmail.com>
	<9719867c0906221455ybc03690n1533f83298217098@mail.gmail.com>
Message-ID: <b087fca00906221522w2cf9b552g74af39b541308b7a@mail.gmail.com>

> Still not working, what does TOT stand for ?
Top Of the Tree. Works for me and Duncan also confirmed that it works
for him. Try to clean your build directory.

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


From aaronngray.lists at googlemail.com  Mon Jun 22 16:11:26 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Tue, 23 Jun 2009 00:11:26 +0100
Subject: [LLVMdev] Getting Circular dependancy between
	libLLVMAlphaAsmPrinter.a and libLLVMAlphaCodeGen.a
In-Reply-To: <b087fca00906221522w2cf9b552g74af39b541308b7a@mail.gmail.com>
References: <9719867c0906221301i56790596p6ef9582f5ac7f8d4@mail.gmail.com> 
	<b087fca00906221325v739492edu42bd8af4cb2aded7@mail.gmail.com> 
	<9719867c0906221455ybc03690n1533f83298217098@mail.gmail.com> 
	<b087fca00906221522w2cf9b552g74af39b541308b7a@mail.gmail.com>
Message-ID: <9719867c0906221611i6872be52g5c9bea08ea354fbb@mail.gmail.com>

Strange, seems to be working now on Linux, I had checkedout and used a clen
build tree.

Sorry for the noise.

Aaron



2009/6/22 Anton Korobeynikov <anton at korobeynikov.info>

> > Still not working, what does TOT stand for ?
> Top Of the Tree. Works for me and Duncan also confirmed that it works
> for him. Try to clean your build directory.
>
> --
>  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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090623/722e7bc5/attachment.html>

From clattner at apple.com  Mon Jun 22 16:43:36 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 22 Jun 2009 16:43:36 -0700
Subject: [LLVMdev] X86 JIT
In-Reply-To: <815322.86897.qm@web110002.mail.gq1.yahoo.com>
References: <815322.86897.qm@web110002.mail.gq1.yahoo.com>
Message-ID: <E348E3F5-0A73-4875-A251-1446E9B46830@apple.com>


On Jun 22, 2009, at 2:19 PM, Kasra wrote:

> Hi,
>
> for some reason I could not get the machine code generator for x86  
> working. The interpreter is the only thing that works, is there  
> anything that I am missing here?

This recently changed.  In your main program, please #include "llvm/ 
Target/TargetSelect.h" and call InitializeNativeTarget(); before  
setting up the execution engine,

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090622/8712d6ad/attachment.html>

From clattner at apple.com  Mon Jun 22 16:44:28 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 22 Jun 2009 16:44:28 -0700
Subject: [LLVMdev] SSE examples
In-Reply-To: <200906222154.24376.jon@ffconsultancy.com>
References: <200906212251.05364.jon@ffconsultancy.com>
	<BLU0-SMTP100ADB2CD5A5DBE4605E851E4390@phx.gbl>
	<200906222154.24376.jon@ffconsultancy.com>
Message-ID: <191030C4-BEC8-4100-8099-3111DFF17742@apple.com>


On Jun 22, 2009, at 1:54 PM, Jon Harrop wrote:

> On Monday 22 June 2009 16:37:41 BGB wrote:
>> as for what targets support which operations, in the case of SSE,  
>> go check
>> the Intel and AMD64 docs.
>
> I was assuming that LLVM's implementations were incomplete. Are they  
> now
> complete? So anything that a CPU can do and LLVM has bindings for is
> implemented?

The issue is that most vector ISA's don't implement every operation.   
If SSE (for example) doesn't implement an operation efficiently,  
you'll get inefficient but correct code.

-Chris


From clattner at apple.com  Mon Jun 22 16:51:27 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 22 Jun 2009 16:51:27 -0700
Subject: [LLVMdev] proposal to simplify isel/asmprinter interaction	with
	globals
In-Reply-To: <E856BD4F-73E5-4E32-9118-A9E4A73DEB72@apple.com>
References: <5E343D57-E3E2-4C45-B3B1-952D90AC5ACF@apple.com>
	<E856BD4F-73E5-4E32-9118-A9E4A73DEB72@apple.com>
Message-ID: <CACDD996-1D8E-493F-854E-CFED902D1BC1@apple.com>


On Jun 22, 2009, at 11:49 AM, Evan Cheng wrote:

>>
>> etc.  The possible set of suffixes and modifiers are all target-
>> specific, so the main code generator would just pass them through (as
>> it does now).
>>
>> Does anyone have any objections to this?
>
> Can you reorg MachineOperand fields while you are at it? :-) Right now
> each MachineOperand uses 8 bits for type, followed by 5 bits for
> various flags, then a whole 8-bit for subreg.  If we use just 3-bit
> for subreg (should be enough?), the target independent part will just
> take up 16-bits and leave plenty of room for target flags.

Yep, I'll clean this up when I get a chance,

-Chris


From clattner at apple.com  Mon Jun 22 16:53:53 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 22 Jun 2009 16:53:53 -0700
Subject: [LLVMdev] Floating point comparison doubt
In-Reply-To: <F536B7C316F9474E9F7091239725AC9A02B1170B@CHN-CL-MAIL01.mchp-main.com>
References: <F536B7C316F9474E9F7091239725AC9A02B1170B@CHN-CL-MAIL01.mchp-main.com>
Message-ID: <D6625AB5-65FE-4FAE-A755-CF3D596159BB@apple.com>


On Jun 22, 2009, at 3:56 AM, Sachin.Punyani at microchip.com wrote:

> Hi,
>
> In unordered floating point comparison before making a call for  
> comparison proper one node called UO_F32 is generated. In targets  
> this node is replaced with a call to __unordsf2.
>
> My doubts here
> 1)  What are these UO_F32 and O_F32 nodes for?
> 2)  What is this function (__unordsf2) supposed to do?
>

uo -> unordered,  o -> ordered.

unordered(x,y) is true if either x or y is a NaN
ordered(x,y) is true if neither x or y is a nan.

See also the CondCode enum in llvm/include/llvm/CodeGen/ 
SelectionDAGNodes.h.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090622/a6bb4afc/attachment.html>

From aaronngray.lists at googlemail.com  Mon Jun 22 17:18:23 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Tue, 23 Jun 2009 01:18:23 +0100
Subject: [LLVMdev] Getting Circular dependancy between
	libLLVMAlphaAsmPrinter.a and libLLVMAlphaCodeGen.a
References: <9719867c0906221301i56790596p6ef9582f5ac7f8d4@mail.gmail.com>
	<b087fca00906221325v739492edu42bd8af4cb2aded7@mail.gmail.com>
	<9719867c0906221455ybc03690n1533f83298217098@mail.gmail.com>
	<b087fca00906221522w2cf9b552g74af39b541308b7a@mail.gmail.com>
	<9719867c0906221611i6872be52g5c9bea08ea354fbb@mail.gmail.com>
Message-ID: <DC268DFAF8324EFBA7650D62816DC263@HPLAPTOP>

Ah, it seems to be my patch triggering it, but it did not do so a few days ago.

Do you know what has changed that could be causing this ?

Thanks,

Aaron

  ----- Original Message ----- 
  From: Aaron Gray 
  To: LLVM Developers Mailing List 
  Sent: Tuesday, June 23, 2009 12:11 AM
  Subject: Re: [LLVMdev] Getting Circular dependancy between libLLVMAlphaAsmPrinter.a and libLLVMAlphaCodeGen.a


  Strange, seems to be working now on Linux, I had checkedout and used a clen build tree.

  Sorry for the noise.

  Aaron


   
  2009/6/22 Anton Korobeynikov <anton at korobeynikov.info>

    > Still not working, what does TOT stand for ?

    Top Of the Tree. Works for me and Duncan also confirmed that it works
    for him. Try to clean your build directory.

    --

    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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090623/d66c382a/attachment.html>

From zhangzhengjian at gmail.com  Mon Jun 22 18:51:59 2009
From: zhangzhengjian at gmail.com (zhengjian zhang)
Date: Tue, 23 Jun 2009 09:51:59 +0800
Subject: [LLVMdev] how to remove MachineInstr ?
Message-ID: <8e3538210906221851g5c06efecj7525adcbc031b846@mail.gmail.com>

Hi,

    I  want to remove   all the MachineInstr of one MachineBasicBlock
, i iterate  the  MachineBasicBlock and remove all the MachineInstr,
but  I can't remove the TerminatorInstr of the MachineBasicBlock ,
are there some  way to walk around it ?


zhangzw


From Sanjiv.Gupta at microchip.com  Mon Jun 22 20:18:58 2009
From: Sanjiv.Gupta at microchip.com (Sanjiv.Gupta at microchip.com)
Date: Mon, 22 Jun 2009 20:18:58 -0700
Subject: [LLVMdev] llvmc for PIC16
References: <4A2633E9.4070207@microchip.com><loom.20090604T142600-116@post.gmane.org><4A28C062.9060307@microchip.com><loom.20090607T070933-452@post.gmane.org><4A35EA76.7090602@microchip.com><3cb898890906150348l2e0d4095seb54de38f95e69f9@mail.gmail.com><4A3656A3.1050403@microchip.com><3cb898890906150730k534167dfxf59677e966477220@mail.gmail.com><4A39F1D7.4060101@microchip.com>
	<3cb898890906180430k5cb0d57fh7c66d10a45c50db0@mail.gmail.com>
Message-ID: <F536B7C316F9474E9F7091239725AC9A4E90DA@CHN-CL-MAIL01.mchp-main.com>


> BTW, Chris's Makefile changes broke llvmc yesterday (r75379). I'm
> working on a fix.

Hi Mikhail,
Did you get a chance to fix this. I still get errors while building examples.

i00202 at ubuntu:~/projects/llvm/tools/llvmc/example/mcc16$ make
make[1]: Entering directory `/home/i00202/projects/llvm/tools/llvmc/example/mcc16/plugins'
make[2]: Entering directory `/home/i00202/projects/llvm/tools/llvmc/example/mcc16/plugins/PIC16Base'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/i00202/projects/llvm/tools/llvmc/example/mcc16/plugins/PIC16Base'
make[1]: Leaving directory `/home/i00202/projects/llvm/tools/llvmc/example/mcc16/plugins'
make[1]: Entering directory `/home/i00202/projects/llvm/tools/llvmc/example/mcc16/driver'
make[1]: *** No rule to make target `/home/i00202/projects/llvm/Debug/lib/plugin_llvmc_PIC16Base.o', needed by `/home/i00202/projects/llvm/Debug/bin/mcc16'.  Stop.
make[1]: Leaving directory `/home/i00202/projects/llvm/tools/llvmc/example/mcc16/driver'
make: *** [all] Error 1

This is with srcdir = objdir.  I get the same error even when srcdir and objdir are separate.

Thanks,
Sanjiv


-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090622/787f20e3/attachment.html>

From the.dead.shall.rise at gmail.com  Tue Jun 23 01:44:42 2009
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Tue, 23 Jun 2009 10:44:42 +0200
Subject: [LLVMdev] llvmc for PIC16
In-Reply-To: <F536B7C316F9474E9F7091239725AC9A4E90DA@CHN-CL-MAIL01.mchp-main.com>
References: <4A2633E9.4070207@microchip.com> <4A28C062.9060307@microchip.com>
	<loom.20090607T070933-452@post.gmane.org>
	<4A35EA76.7090602@microchip.com>
	<3cb898890906150348l2e0d4095seb54de38f95e69f9@mail.gmail.com>
	<4A3656A3.1050403@microchip.com>
	<3cb898890906150730k534167dfxf59677e966477220@mail.gmail.com>
	<4A39F1D7.4060101@microchip.com>
	<3cb898890906180430k5cb0d57fh7c66d10a45c50db0@mail.gmail.com>
	<F536B7C316F9474E9F7091239725AC9A4E90DA@CHN-CL-MAIL01.mchp-main.com>
Message-ID: <3cb898890906230144l2773268cl3feb27c5283e992f@mail.gmail.com>

Hi Sanjiv,

2009/6/23  <Sanjiv.Gupta at microchip.com>:
>
>> BTW, Chris's Makefile changes broke llvmc yesterday (r75379). I'm
>> working on a fix.
>
> Hi Mikhail,
> Did you get a chance to fix this. I still get errors while building
> examples.

Not yet, sorry - I was away during the weekend. I'll fix this issue
either today or tomorrow. For now, please use the version prior to
r75379.

-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments


From eric.rannaud at gmail.com  Tue Jun 23 02:31:36 2009
From: eric.rannaud at gmail.com (Eric Rannaud)
Date: Tue, 23 Jun 2009 02:31:36 -0700
Subject: [LLVMdev] X86 JIT
In-Reply-To: <E348E3F5-0A73-4875-A251-1446E9B46830@apple.com>
References: <815322.86897.qm@web110002.mail.gq1.yahoo.com>
	<E348E3F5-0A73-4875-A251-1446E9B46830@apple.com>
Message-ID: <5f3c152b0906230231p52dbe0c2r31fb23327e4848a0@mail.gmail.com>

On Mon, Jun 22, 2009 at 4:43 PM, Chris Lattner <clattner at apple.com>
wrote:
>
> On Jun 22, 2009, at 2:19 PM, Kasra wrote:
>
> Hi,
>
> for some reason I could not get the machine code generator for x86
> working. The interpreter is the only thing that works, is there
> anything that I am missing here?
>
> This recently changed.  In your main program, please #include
> "llvm/Target/TargetSelect.h" and call InitializeNativeTarget(); before
> setting up the execution engine,


Actually, you also need to include:

#include <llvm/ExecutionEngine/JIT.h>
or
#include <llvm/ExecutionEngine/Interpreter.h>

If not, you can get a segfault.


To reproduce, apply:

Index: tools/lli/lli.cpp
===================================================================
--- tools/lli/lli.cpp   (revision 73952)
+++ tools/lli/lli.cpp   (working copy)
@@ -18,8 +18,9 @@
 #include "llvm/Type.h"
 #include "llvm/Bitcode/ReaderWriter.h"
 #include "llvm/CodeGen/LinkAllCodegenComponents.h"
-#include "llvm/ExecutionEngine/JIT.h"
-#include "llvm/ExecutionEngine/Interpreter.h"
+//#include "llvm/ExecutionEngine/JIT.h"
+//#include "llvm/ExecutionEngine/Interpreter.h"
+#include "llvm/ExecutionEngine/ExecutionEngine.h"
 #include "llvm/ExecutionEngine/GenericValue.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/ManagedStatic.h"


Note that lli compiles OK with the patch. However:


[tmp]$ lli test6.bc
0   lli             0x0000000000d91488
1   lli             0x0000000000d91969
2   libpthread.so.0 0x00000034cb20ed30
3   lli             0x0000000000af7c02
llvm::SmallVectorImpl<llvm::ModuleProvider*>::size() const + 12
4   lli             0x0000000000af5bfc
llvm::ExecutionEngine::runStaticConstructorsDestructors(bool) + 40
5   lli             0x0000000000772b33 main + 1366
6   libc.so.6       0x00000034ca61e32a __libc_start_main + 250
7   lli             0x0000000000772009
Stack dump:
0.      Program arguments: lli test6.bc
Segmentation fault


I do not quite understand why, but it appears that the constructor of
the static variable

static struct RegisterJIT {
  RegisterJIT() { JIT::Register(); }
} JITRegistrator;

in lib/ExecutionEngine/JIT/JIT.cpp is only called if either JIT.h or
Interpreter.h is included. When they are not included, JIT::Register()
is not called, and ExecutionEngine::JITCtor and
ExecutionEngine::InterpCtor are both NULL, and ExecutionEngine::create()
returns NULL.

This is not caught by (in lli.cpp):

  if (!EE && !ErrorMsg.empty()) {
    std::cerr << argv[0] << ":error creating EE: " << ErrorMsg << "\n";
    exit(1);
  }

as ErrorMsg is empty. Then it segfaults line 190.

This is quite nasty behavior. I don't know what the proper fix is, but
relying on static constructors seems misplaced. And certainly, a missing
header should not result in a runtime fault.

Thanks,
Eric.



From gordonhenriksen at me.com  Tue Jun 23 04:18:43 2009
From: gordonhenriksen at me.com (Gordon Henriksen)
Date: Tue, 23 Jun 2009 07:18:43 -0400
Subject: [LLVMdev] Adding safe-point code generation
In-Reply-To: <bb55930e0906212249k6dd406b4x514867cc2d02086c@mail.gmail.com>
References: <bb55930e0906212249k6dd406b4x514867cc2d02086c@mail.gmail.com>
Message-ID: <88B97DD9-F834-4629-9A67-FE5D429A7EE5@me.com>

Hi Jeffrey,

On 2009-06-22, at 01:49, Jeffrey Yasskin wrote:

> I need to add thread-switching support to Unladen Swallow's JIT, and  
> LLVM's safe point support looks like a good way to get code into all  
> the right places. However, http://llvm.org/docs/GarbageCollection.html#collector-algos 
>  points out that there's no way to emit code at safe points yet, and  
> there are no loop safe points at all. So I'll be trying to implement  
> them.
>
> Is there anything I should know before starting?

Sounds like you've got the right idea.

> One way to do this might be to add a FunctionPass to  
> LLVMTargetMachine::addCommonCodeGenPasses() alongside  
> createGCLoweringPass(), which would insert user-defined code for  
> safe points. Unfortunately, code inserted there would stick around  
> in the IR after the machine code was emitted, and if the function  
> were JITted again, we'd get duplicate safe points.

Unfortunately, I don't believe this is workable. It would make this  
work much easier if it were.

> Another way to do it might be to add a MachineFunction pass next to  
> createGCMachineCodeAnalysisPass() (or instead of it), which could  
> emit appropriate MachineInstructions to implement the safe point.  
> This, of course, forces safe points to be written in  
> MachineInstructions instead of IR instructions, which isn't ideal.

I think this is the way to go, though it's also the most involved. My  
primary rationale is that code generation can hack on the CFG, even  
introducing loops where there were none expressed in the IR. It could  
be that I'm being unnecessarily pessimistic on this point, though.

As a specific example of the code generator hacking on the CFG, take  
atomic operations which expand to loops on architectures which use  
load-reserved/store-conditional to implement these primitives. It may  
not be necessary or desirable to add safe points to these loops, but  
perhaps should be preferred on the basis o correctness.

As another example, consider a 64-bit integer divide on a 32-bit  
architecture expanding to a libcall. Some, but perhaps not all,  
collection algorithms would want to emit safe point code for this  
call, but it simply does not exist in the IR to instrument.

Also, code injection of the form 'give me 8 bytes of noops at each  
safe point' and 'insert a cold instruction sequence at the end of the  
function' are best expressed at the machine code level. Safe points  
are hot code and unusual, target-specific techniques are regularly  
used with them if you survey the literature, so a design which  
accommodates that reality is preferred, even though hacking on the  
MachineFunction representation is less pleasant than the IR.

One element of this design that is desirable from a design perspective  
is that it preserves the original IR. Chris has said that it's a long- 
term goal of LLVM to not mangle the Function during code generation,  
and this moves in that direction instead of regressing.

> Another way might be to run a pass over the IR inserting  
> llvm.safepoint() calls, which could be implemented as a function in  
> the module. Then we'd want a MachineFunction pass to inline this for  
> us during codegen. The llvm.safepoint() calls could be easily  
> identified and removed if the IR needs to be re-used.

I see this as fairly equivalent to the first option.

Also, regardless, stop point markers (a label is actually generated)  
need to survive as such into the MachineFunction representation else  
we'll never be able to generate a register map.

Hope that helps,
Gordon


P.S. There's an interesting circularity which I may not have accounted  
for in the original design: If code is injected at each safe point,  
and a call instruction is injected, do we need to generate another  
safe point for that call? Clearly, the expansion of a safe point  
cannot be recursive with itself; but I think that we should allow  
generating a register map at the return address of that call, just as  
some collectors may want to instrument the libcall case discussed above.

Actually, this distinction between safe points for inserting code and  
safe points for frame maps is probably is a critical design issue for  
your use case. Our current definition of a safe point is at the return  
address of a call instruction, which is precisely what's required to  
call the stack. This is NOT the location where you want to add a call  
to your runtime.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090623/6c07a73a/attachment.html>

From amanous at softlab.ece.ntua.gr  Tue Jun 23 06:29:22 2009
From: amanous at softlab.ece.ntua.gr (Angelos Manousaridis)
Date: Tue, 23 Jun 2009 16:29:22 +0300
Subject: [LLVMdev] Garbage collection implementation
Message-ID: <20090623132922.GA31918@softlab.ece.ntua.gr>

I am using LLVM as the last stage of a compiler in order to easily produce a
binary in native code. My compiler is implemented in Ocaml and has various
layers of languages. In the last layer prior to LLVM, I have a value which has
been converted to CPS, closure and hoisting (of functions).

I am now trying to write a garbage collector for this language. The shadow
stack is not suitable for me, because essentially there is no stack in my case!
All the function calls are tail calls and without tail recursive optimization
and stack re-use, the binary is useless.

My goal for now is to write a simple stop-the-world, semispace collector. To
cut a long story sort, I need to implement an allocation function like this:

if ( there is enough space ) {
  allocate space;
} else {
  dump all live physical registers on the stack;
  garbage collect;
  restore from stack, using the new locations;
}

The tricky part is the "dump all live registers". I spent quite some time
reading the documentation and have come up to two alternatives. Either
implement a new pass which reads the live variable analysis and spills all
registers to the stack at this point, or implement a new intrinsic which spills
all registers to the stack (after gc, I have to reload registers manually).

Neither of these ideas appears easy, and I am wondering if there is a simpler
way around this. To my understanding, there is neither a register map or any
sort of runtime-contract regarding the registers. Also, I need to work my way
among the LLVM optimizations which move values around registers (for instance
the fastcc convention which is essential for tail recursive optimization).

--
Angelos Manousaridis


From gordonhenriksen at me.com  Tue Jun 23 06:59:04 2009
From: gordonhenriksen at me.com (Gordon Henriksen)
Date: Tue, 23 Jun 2009 09:59:04 -0400
Subject: [LLVMdev] Adding safe-point code generation
In-Reply-To: <88B97DD9-F834-4629-9A67-FE5D429A7EE5@me.com>
References: <bb55930e0906212249k6dd406b4x514867cc2d02086c@mail.gmail.com>
	<88B97DD9-F834-4629-9A67-FE5D429A7EE5@me.com>
Message-ID: <851D3C95-87B5-4B57-A826-55EA6D228C07@me.com>

On 2009-06-23, at 07:18, Gordon Henriksen wrote:

> Actually, this distinction between safe points for inserting code  
> and safe points for frame maps is probably is a critical design  
> issue for your use case. Our current definition of a safe point is  
> at the return address of a call instruction, which is precisely  
> what's required to call the stack. This is NOT the location where  
> you want to add a call to your runtime.

“... precisely what's required to walk the stack ...”, rather.

— Gordon


From aaronngray.lists at googlemail.com  Tue Jun 23 07:17:24 2009
From: aaronngray.lists at googlemail.com (Aaron Gray)
Date: Tue, 23 Jun 2009 15:17:24 +0100
Subject: [LLVMdev] Getting Circular dependancy between
	libLLVMAlphaAsmPrinter.a and libLLVMAlphaCodeGen.a
In-Reply-To: <DC268DFAF8324EFBA7650D62816DC263@HPLAPTOP>
References: <9719867c0906221301i56790596p6ef9582f5ac7f8d4@mail.gmail.com> 
	<b087fca00906221325v739492edu42bd8af4cb2aded7@mail.gmail.com> 
	<9719867c0906221455ybc03690n1533f83298217098@mail.gmail.com> 
	<b087fca00906221522w2cf9b552g74af39b541308b7a@mail.gmail.com> 
	<9719867c0906221611i6872be52g5c9bea08ea354fbb@mail.gmail.com> 
	<DC268DFAF8324EFBA7650D62816DC263@HPLAPTOP>
Message-ID: <9719867c0906230717h2a4aa35bm4b1c70a1d4ce3c4a@mail.gmail.com>

Okay, I've got it, a very simple code change.

Aaron

2009/6/23 Aaron Gray <aaronngray.lists at googlemail.com>

>  Ah, it seems to be my patch triggering it, but it did not do so a few
> days ago.
>
> Do you know what has changed that could be causing this ?
>
> Thanks,
>
> Aaron
>
>
> ----- Original Message -----
> *From:* Aaron Gray <aaronngray.lists at googlemail.com>
> *To:* LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> *Sent:* Tuesday, June 23, 2009 12:11 AM
> *Subject:* Re: [LLVMdev] Getting Circular dependancy between
> libLLVMAlphaAsmPrinter.a and libLLVMAlphaCodeGen.a
>
> Strange, seems to be working now on Linux, I had checkedout and used a clen
> build tree.
>
> Sorry for the noise.
>
> Aaron
>
>
>
> 2009/6/22 Anton Korobeynikov <anton at korobeynikov.info>
>
>> > Still not working, what does TOT stand for ?
>> Top Of the Tree. Works for me and Duncan also confirmed that it works
>> for him. Try to clean your build directory.
>>
>> --
>>  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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090623/7e31069f/attachment.html>

From MichaelGraumann at gmx.net  Tue Jun 23 07:36:51 2009
From: MichaelGraumann at gmx.net (Michael Graumann)
Date: Tue, 23 Jun 2009 16:36:51 +0200
Subject: [LLVMdev] physical registers content/data print out
Message-ID: <000801c9f410$0c750720$255f1560$@net>

Hi 

I am using LLVM version 2.5. I am trying to build traces, using lli
-print-machineinstrs to print out the machine instructions. But I don't get
access to the physical registers values (e.g.  %R4=??). Is it possible to
print out this physical registers values? I'd tried to modify the
MachineInstr.cpp, but I can't find the right place/value.

 

I hope anybody can help me 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090623/05b58f4a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6952 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090623/05b58f4a/attachment.bin>

From anton at korobeynikov.info  Tue Jun 23 08:20:45 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Tue, 23 Jun 2009 19:20:45 +0400
Subject: [LLVMdev] physical registers content/data print out
In-Reply-To: <000801c9f410$0c750720$255f1560$@net>
References: <000801c9f410$0c750720$255f1560$@net>
Message-ID: <b087fca00906230820r489a881bm50b201c80b04097d@mail.gmail.com>

Hello, Michael

> I am using LLVM version 2.5. I am trying to build traces, using lli –print-machineinstrs to print out the machine instructions. But I don’t get access to the physical registers values (e.g.  %R4=??). Is it possible to print out this physical registers values? I’d tried to modify the MachineInstr.cpp, but I can’t find the right place/value.
-print-machineinstrs will print instructions after the codegen, not
traces. There is currently no way to obtain neither traces nor values
of registers. LLVM executes stuff on per-function basis, not per
instruction, also JIT does not model registers in any way.

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



From MichaelFrerichs at my.unt.edu  Tue Jun 23 10:04:01 2009
From: MichaelFrerichs at my.unt.edu (MichaelFrerichs)
Date: Tue, 23 Jun 2009 17:04:01 +0000
Subject: [LLVMdev] LLVM Automatic Pool Allocation
Message-ID: <39AA8FECDA2EF64FBF40CA36E179EDFF0DD5739E@BL2PRD0102MB003.prod.exchangelabs.com>

My name is Michael Frerichs and I am a part of a research team led by Dr. Krishna Kavi at the University of North Texas. Our current work focuses on optimizing dynamic memory for multiprocessor systems. We are interested in the LLVM infrastructure and the Automatic Pool Allocation technique. We believe this tool could be useful to our research and wondered if we could utilize your implementations of the Automatic Pool Allocation tool for multiprocessing applications.

Thank you,
Michael Frerichs



From criswell at cs.uiuc.edu  Tue Jun 23 10:36:06 2009
From: criswell at cs.uiuc.edu (John Criswell)
Date: Tue, 23 Jun 2009 12:36:06 -0500
Subject: [LLVMdev] LLVM Automatic Pool Allocation
In-Reply-To: <39AA8FECDA2EF64FBF40CA36E179EDFF0DD5739E@BL2PRD0102MB003.prod.exchangelabs.com>
References: <39AA8FECDA2EF64FBF40CA36E179EDFF0DD5739E@BL2PRD0102MB003.prod.exchangelabs.com>
Message-ID: <4A411286.8020501@cs.uiuc.edu>

MichaelFrerichs wrote:
> My name is Michael Frerichs and I am a part of a research team led by Dr. Krishna Kavi at the University of North Texas. Our current work focuses on optimizing dynamic memory for multiprocessor systems. We are interested in the LLVM infrastructure and the Automatic Pool Allocation technique. We believe this tool could be useful to our research and wondered if we could utilize your implementations of the Automatic Pool Allocation tool for multiprocessing applications.
>   
Yes.

The Automatic Pool Allocation transform is publicly available (though
not as well publicized as LLVM).  To get the source code, use the
following command:

cd llvm/projects
svn co http://llvm.org/svn/llvm-project/poolalloc/trunk poolalloc

If you're checking out LLVM for the first time, the poolalloc project
should be auto-configured when you run the configure script in the llvm
top level directory.  If you already have LLVM configured and built, you
can configure poolalloc separately by running its configure script.

The poolalloc code currently compiles with top-of-tree (also known as
mainline) LLVM.  We keep the code up-to-date since we use it in the
SAFECode project, although it may have experienced some bitrot over time.

If you have any questions on pool allocation, please email llvmdev. 
There are several people on the list (myself included) who use parts of
the poolalloc source code to various degrees.

-- John T.

> Thank you,
> Michael Frerichs
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   



From jon at ffconsultancy.com  Tue Jun 23 12:11:36 2009
From: jon at ffconsultancy.com (Jon Harrop)
Date: Tue, 23 Jun 2009 20:11:36 +0100
Subject: [LLVMdev] LLVM Automatic Pool Allocation
In-Reply-To: <4A411286.8020501@cs.uiuc.edu>
References: <39AA8FECDA2EF64FBF40CA36E179EDFF0DD5739E@BL2PRD0102MB003.prod.exchangelabs.com>
	<4A411286.8020501@cs.uiuc.edu>
Message-ID: <200906232011.37010.jon@ffconsultancy.com>

On Tuesday 23 June 2009 18:36:06 John Criswell wrote:
> The Automatic Pool Allocation transform is publicly available (though
> not as well publicized as LLVM).

What exactly is it? (just curious!)

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e


From clattner at apple.com  Tue Jun 23 11:38:40 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 23 Jun 2009 11:38:40 -0700
Subject: [LLVMdev] LLVM Automatic Pool Allocation
In-Reply-To: <200906232011.37010.jon@ffconsultancy.com>
References: <39AA8FECDA2EF64FBF40CA36E179EDFF0DD5739E@BL2PRD0102MB003.prod.exchangelabs.com>
	<4A411286.8020501@cs.uiuc.edu>
	<200906232011.37010.jon@ffconsultancy.com>
Message-ID: <BE917B98-34C3-4132-A0F0-D3F9FB55611A@apple.com>


On Jun 23, 2009, at 12:11 PM, Jon Harrop wrote:

> On Tuesday 23 June 2009 18:36:06 John Criswell wrote:
>> The Automatic Pool Allocation transform is publicly available (though
>> not as well publicized as LLVM).
>
> What exactly is it? (just curious!)

Description here:
http://llvm.org/pubs/2005-05-21-PLDI-PoolAlloc.html

More info with applications here:
http://llvm.org/pubs/2005-05-04-LattnerPHDThesis.html

-Chris


From eric.rannaud at gmail.com  Tue Jun 23 11:56:24 2009
From: eric.rannaud at gmail.com (Eric Rannaud)
Date: Tue, 23 Jun 2009 11:56:24 -0700
Subject: [LLVMdev] X86 JIT
In-Reply-To: <5f3c152b0906230231p52dbe0c2r31fb23327e4848a0@mail.gmail.com>
References: <815322.86897.qm@web110002.mail.gq1.yahoo.com>
	<E348E3F5-0A73-4875-A251-1446E9B46830@apple.com>
	<5f3c152b0906230231p52dbe0c2r31fb23327e4848a0@mail.gmail.com>
Message-ID: <20090623185624.GA4959@nc050>

On Tue, Jun 23, 2009 at 02:31:36AM -0700, Eric Rannaud wrote:
> On Mon, Jun 22, 2009 at 4:43 PM, Chris Lattner <clattner at apple.com>
> wrote:
> I do not quite understand why, but it appears that the constructor of
> the static variable
> 
> static struct RegisterJIT {
>   RegisterJIT() { JIT::Register(); }
> } JITRegistrator;
> 
> in lib/ExecutionEngine/JIT/JIT.cpp is only called if either JIT.h or
> Interpreter.h is included. When they are not included, JIT::Register()
> is not called, and ExecutionEngine::JITCtor and
> ExecutionEngine::InterpCtor are both NULL, and ExecutionEngine::create()
> returns NULL.
>
> ...
>
> This is quite nasty behavior. I don't know what the proper fix is, but
> relying on static constructors seems misplaced. And certainly, a missing
> header should not result in a runtime fault.

So, at a minimum, JITRegistrator and InterpRegistrator should not have
static linkage. But that is still not enough. As they both are in a
static library (libLLVMJIT.a and libLLVMInterpreter.a), to appear in the
final 'lli' binary all the time, the linker flag --whole-archive needs
to be used (see ld(1)). Without the flag, JITRegistrator and
InterpRegistrator are only included if the .o they live in (JIT.o and
Interpreter.o) are used. This becomes very obscure.

I would personally fix this by getting rid of global variable
constructors for initialization purposes. Otherwise, I'm not sure where
such a linker flag should be added. It would also need to be added to
`llvm-config --ldflags`.

Thanks,
Eric.


From eric.rannaud at gmail.com  Tue Jun 23 12:04:14 2009
From: eric.rannaud at gmail.com (Eric Rannaud)
Date: Tue, 23 Jun 2009 12:04:14 -0700
Subject: [LLVMdev] [PATCH] Catch NULL return value of
	ExecutionEngine::create()
In-Reply-To: <5f3c152b0906230231p52dbe0c2r31fb23327e4848a0@mail.gmail.com>
References: <815322.86897.qm@web110002.mail.gq1.yahoo.com>
	<E348E3F5-0A73-4875-A251-1446E9B46830@apple.com>
	<5f3c152b0906230231p52dbe0c2r31fb23327e4848a0@mail.gmail.com>
Message-ID: <20090623190414.GB4959@nc050>

ExecutionEngine::create() can return NULL with an empty error message
(admittedly, it did so because of global variable initialization
problems). The code currently lets NULL go through if ErrorMsg is empty,
and segfaults later.

When EE is NULL but ErrorMsg is empty, simply do not try to
print it and exit.

Index: tools/lli/lli.cpp                                             
===================================================================  
--- tools/lli/lli.cpp   (revision 73978)                             
+++ tools/lli/lli.cpp   (working copy)
@@ -144,8 +144,11 @@
   InitializeNativeTarget();

   EE = ExecutionEngine::create(MP, ForceInterpreter, &ErrorMsg, OLvl);
-  if (!EE && !ErrorMsg.empty()) {
   -    std::cerr << argv[0] << ":error creating EE: " << ErrorMsg <<
        "\n";
+  if (!EE) {
+    if (!ErrorMsg.empty())
+      std::cerr << argv[0] << ":error creating EE: " << ErrorMsg <<
"\n";
+    else
+      std::cerr << argv[0] << ":error creating EE\n";
     exit(1);
   }


From jyasskin at google.com  Tue Jun 23 12:18:57 2009
From: jyasskin at google.com (Jeffrey Yasskin)
Date: Tue, 23 Jun 2009 12:18:57 -0700
Subject: [LLVMdev] Adding safe-point code generation
In-Reply-To: <88B97DD9-F834-4629-9A67-FE5D429A7EE5@me.com>
References: <bb55930e0906212249k6dd406b4x514867cc2d02086c@mail.gmail.com>
	<88B97DD9-F834-4629-9A67-FE5D429A7EE5@me.com>
Message-ID: <bb55930e0906231218x719327fav745c12871dbd6290@mail.gmail.com>

On Tue, Jun 23, 2009 at 4:18 AM, Gordon Henriksen <gordonhenriksen at me.com>wrote:

> Hi Jeffrey,
> On 2009-06-22, at 01:49, Jeffrey Yasskin wrote:
>
> I need to add thread-switching support to Unladen Swallow's JIT, and LLVM's
> safe point support looks like a good way to get code into all the right
> places. However,
> http://llvm.org/docs/GarbageCollection.html#collector-algos points
> out that there's no way to emit code at safe points yet, and there are
> no loop safe points at all. So I'll be trying to implement them.
>
> Is there anything I should know before starting?
>
>
> Sounds like you've got the right idea.
>
> One way to do this might be to add a FunctionPass
> to LLVMTargetMachine::addCommonCodeGenPasses()
> alongside createGCLoweringPass(), which would insert user-defined code for
> safe points. Unfortunately, code inserted there would stick around in the IR
> after the machine code was emitted, and if the function were JITted again,
> we'd get duplicate safe points.
>
>
> Unfortunately, I don't believe this is workable. It would make this work
> much easier if it were.
>
> Another way to do it might be to add a MachineFunction pass next
> to createGCMachineCodeAnalysisPass() (or instead of it), which could
> emit appropriate MachineInstructions to implement the safe point. This,
> of course, forces safe points to be written in MachineInstructions instead
> of IR instructions, which isn't ideal.
>
>
> I think this is the way to go, though it's also the most involved. My
> primary rationale is that code generation can hack on the CFG, even
> introducing loops where there were none expressed in the IR. It could be
> that I'm being unnecessarily pessimistic on this point, though.
>
> As a specific example of the code generator hacking on the CFG, take atomic
> operations which expand to loops on architectures which use
> load-reserved/store-conditional to implement these primitives. It may not be
> necessary or desirable to add safe points to these loops, but perhaps should
> be preferred on the basis o correctness.
>

As another example, consider a 64-bit integer divide on a 32-bit
> architecture expanding to a libcall. Some, but perhaps not all, collection
> algorithms would want to emit safe point code for this call, but it simply
> does not exist in the IR to instrument.
>

I'm worried that it'll be necessary for some garbage collectors and hurt
performance too much for others. Should it be configurable? I don't need to
insert safe points in such loops and calls for my use, so I'd try to make it
extensible, but then leave support for these loops and calls to someone who
actually needs them.

Also, code injection of the form 'give me 8 bytes of noops at each safe
> point' and 'insert a cold instruction sequence at the end of the function'
> are best expressed at the machine code level. Safe points are hot code and
> unusual, target-specific techniques are regularly used with them if you
> survey the literature, so a design which accommodates that reality is
> preferred, even though hacking on the MachineFunction representation is less
> pleasant than the IR.
>

I'd like to allow target-specific techniques, but also allow
target-independent techniques, and the target-independent techniques are
more important for what I'm actually doing. Now that I've looked into
MachineInstructions more, it looks like it's impossible to use them in a
target-independent way.

>
> One element of this design that is desirable from a design perspective is
> that it preserves the original IR. Chris has said that it's a long-term goal
> of LLVM to not mangle the Function during code generation, and this moves in
> that direction instead of regressing.
>

I definitely like that feature.

Another way might be to run a pass over the IR inserting llvm.safepoint()
> calls, which could be implemented as a function in the module. Then we'd
> want a MachineFunction pass to inline this for us during codegen. The
> llvm.safepoint() calls could be easily identified and removed if the IR
> needs to be re-used.
>
>
> I see this as fairly equivalent to the first option.
>

I don't, because the user can control how they lower llvm.safepoint(). For
uses like mine, where I'd rather write the safe point in IR, I can implement
it as a function (if I have a selectiondag-level inliner). For more advanced
garbage collectors, they can implement it as a custom lowering in their
target. The biggest downside of an llvm.safepoint intrinsic would be that it
couldn't capture loops and calls introduced by lowering, unless those
lowerings explicitly introduced new safepoints.

>
> Also, regardless, stop point markers (a label is actually generated) need
> to survive as such into the MachineFunction representation else we'll never
> be able to generate a register map.
>
> Hope that helps,
> Gordon
>
>
> P.S. There's an interesting circularity which I may not have accounted for
> in the original design: If code is injected at each safe point, and a call
> instruction is injected, do we need to generate *another* safe point for
> that call? Clearly, the expansion of a safe point cannot be recursive with
> itself; but I think that we should allow generating a register map at the
> return address of that call, just as some collectors may want to instrument
> the libcall case discussed above.
>
> Actually, this distinction between safe points for inserting code and safe
> points for frame maps is probably is a critical design issue for your use
> case. Our current definition of a safe point is at the return address of a
> call instruction, which is precisely what's required to walk the stack. This
> is NOT the location where you want to add a call to your runtime.
>

I think you're saying that we need two kinds of safe points: points at which
to insert code, and points that the GCFunctionInfo::iterator traverses. The
code-inserting safe points could insert traversed safe points.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090623/57aa3d10/attachment.html>

From hannibal_08 at mail.com  Tue Jun 23 12:26:06 2009
From: hannibal_08 at mail.com (hannibal hannibal)
Date: Tue, 23 Jun 2009 14:26:06 -0500
Subject: [LLVMdev] lli aborts on arm QEMU
Message-ID: <20090623192606.0D42BBE407E@ws1-9.us4.outblaze.com>

I get the following error when I try to run arm lli on QEMU:

lli: llvm-arm/src/llvm/include/llvm/ADT/ilist.h:197: typename bidirectional_iterator<NodeTy, int>::reference llvm::ilist_iterator<NodeTy>::operator*() const [with NodeTy = llvm::RecyclerStruct]: Assertion `Traits::getNext(NodePtr) != 0 && "Dereferencing end()!"' failed.
0   lli 0x006abbfc
Stack dump:
0.	Program arguments: ./lli hello2.bc 
1.	Running pass 'ARM Instruction Selection' on function '@main'
Aborted.


Is it a bug or I am doing something stupid?


Thanks
hannibal





-- 
Be Yourself @ mail.com!
Choose From 200+ Email Addresses
Get a Free Account at www.mail.com




From jon at ffconsultancy.com  Tue Jun 23 14:35:38 2009
From: jon at ffconsultancy.com (Jon Harrop)
Date: Tue, 23 Jun 2009 22:35:38 +0100
Subject: [LLVMdev] Garbage collection implementation
In-Reply-To: <20090623132922.GA31918@softlab.ece.ntua.gr>
References: <20090623132922.GA31918@softlab.ece.ntua.gr>
Message-ID: <200906232235.39020.jon@ffconsultancy.com>

On Tuesday 23 June 2009 14:29:22 Angelos Manousaridis wrote:
> I am using LLVM as the last stage of a compiler in order to easily produce
> a binary in native code. My compiler is implemented in Ocaml and has
> various layers of languages. In the last layer prior to LLVM, I have a
> value which has been converted to CPS, closure and hoisting (of functions).
>
> I am now trying to write a garbage collector for this language. The shadow
> stack is not suitable for me, because essentially there is no stack in my
> case!

I don't follow. Shadow stack is overkill because you only ever have one stack 
frame but it should work perfectly.

> All the function calls are tail calls and without tail recursive 
> optimization and stack re-use, the binary is useless.
>
> My goal for now is to write a simple stop-the-world, semispace collector.
> To cut a long story sort, I need to implement an allocation function like
> this:
>
> if ( there is enough space ) {
>   allocate space;
> } else {
>   dump all live physical registers on the stack;
>   garbage collect;
>   restore from stack, using the new locations;
> }
>
> The tricky part is the "dump all live registers".

The solution I used in HLVM is essentially to always keep all 
registers "dumped". Specifically, they are dumped as soon as they go live and 
reclaimed at the end of each function. That is grossly inefficient in theory 
but it is easy and, in fact, performance can still be very good indeed (e.g. 
several times faster than OCaml).

> I spent quite some time 
> reading the documentation and have come up to two alternatives. Either
> implement a new pass which reads the live variable analysis and spills all
> registers to the stack at this point, or implement a new intrinsic which
> spills all registers to the stack (after gc, I have to reload registers
> manually).
>
> Neither of these ideas appears easy, and I am wondering if there is a
> simpler way around this.

The simplest way is surely to reuse HLVM because it provides everything you 
need and is even written in the right language! ;-)

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e


From the.dead.shall.rise at gmail.com  Tue Jun 23 13:49:38 2009
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Tue, 23 Jun 2009 22:49:38 +0200
Subject: [LLVMdev] llvmc for PIC16
In-Reply-To: <F536B7C316F9474E9F7091239725AC9A4E90DA@CHN-CL-MAIL01.mchp-main.com>
References: <4A2633E9.4070207@microchip.com> <4A28C062.9060307@microchip.com>
	<loom.20090607T070933-452@post.gmane.org>
	<4A35EA76.7090602@microchip.com>
	<3cb898890906150348l2e0d4095seb54de38f95e69f9@mail.gmail.com>
	<4A3656A3.1050403@microchip.com>
	<3cb898890906150730k534167dfxf59677e966477220@mail.gmail.com>
	<4A39F1D7.4060101@microchip.com>
	<3cb898890906180430k5cb0d57fh7c66d10a45c50db0@mail.gmail.com>
	<F536B7C316F9474E9F7091239725AC9A4E90DA@CHN-CL-MAIL01.mchp-main.com>
Message-ID: <3cb898890906231349l47a91d6m57c48fa8fc9617b@mail.gmail.com>

Hi Sanjiv,

2009/6/23 <Sanjiv.Gupta at microchip.com>
>
> > BTW, Chris's Makefile changes broke llvmc yesterday (r75379). I'm
> > working on a fix.
>
> Hi Mikhail,
> Did you get a chance to fix this. I still get errors while building examples.
>

This issue should be fixed now (r74001+).


--
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments



From mjr at cs.wisc.edu  Tue Jun 23 14:13:39 2009
From: mjr at cs.wisc.edu (Matt Renzelmann)
Date: Tue, 23 Jun 2009 16:13:39 -0500
Subject: [LLVMdev] How to add a trivial LLVM intrinsic
Message-ID: <005301c9f447$7ddc1340$799439c0$@wisc.edu>

Hello,

As an experiment, I'm simply trying to add a trivial intrinsic to LLVM, but
I'm having trouble, which suggests that I'm overlooking the obvious ;)
Platform is GCC-4.2.4/LLVM from SVN/x86.

First, I've read the page here about 10 times, so I'll speculate that my
reading comprehension is lacking:
http://www.llvm.org/docs/ExtendingLLVM.html

Code I've added to the bottom of the llvm/include/llvm/Intrinsics.td file:
-----------------
def int_test_intrinsic :
        Intrinsic<[llvm_i32_ty],
                  [llvm_i32_ty],
                  [],
                  "llvm.test.intrinsic">;
-----------------

Code I've added to visitBuiltinCall in
llvm/lib/Target/CBackend/CBackend.cpp:
-----------------
  case Intrinsic::test_intrinsic:
    return true;
-----------------

I've not added any code to llvm/lib/Target/X86 because when I did, I
received a tablegen error.  I think I'm not understanding the difference
between an intrinsic that maps directly to a single machine instruction, and
a more complex intrinsic that invokes a C function.

In particular, I tried adding:
def int_test_and_clear_bit : X86Inst;

to the end of X86.td, but that resulted in a tablegen compilation error.

Code I've added to the end of LowerIntrinsicCall in
/lib/CodeGen/IntrinsicLowering.cpp:
-----------------
  case Intrinsic::test_intrinsic:
      break;
-----------------

Note that the intent is to make this intrinsic a NOOP, just as an
experiment.

But alas, the following trivial test program does not work:

-----------------
#include <stdio.h>

int llvm_test_intrinsic(int) asm ("llvm.test.intrinsic");

int bar (int blah) {
    return llvm_test_intrinsic (blah);
}

int main() {
    int x = 3;
    bar (x);
    return 0;
}
-----------------
After invoking:
llvm-gcc -g test.c -o test.native
-----------------
The compiler returns:
cc1: Function.cpp:323: unsigned int llvm::Function::getIntrinsicID(bool)
const: Assertion `noAssert && "Invalid LLVM intrinsic name"' failed.
test.c:24: internal compiler error: Aborted
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://developer.apple.com/bugreporter> for instructions.
-----------------

So, it's clear I'm missing something, or lots of things.  Any help would be
appreciated :)  I'm sure this is easy.

Thanks and regards,
Matt



From nicholas at mxc.ca  Tue Jun 23 20:35:13 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Tue, 23 Jun 2009 20:35:13 -0700
Subject: [LLVMdev] reading untrusted bitcode
In-Reply-To: <f5aa3e9b0906062131u3e4b16d2g1d8046d3bb288d53@mail.gmail.com>
References: <4A2B189A.10307@mxc.ca>
	<f5aa3e9b0906062131u3e4b16d2g1d8046d3bb288d53@mail.gmail.com>
Message-ID: <4A419EF1.3050707@mxc.ca>

Eli Friedman wrote:
> On Sat, Jun 6, 2009 at 6:32 PM, Nick Lewycky<nicholas at mxc.ca> wrote:
>> Whose responsibility is it supposed to be to check types for legality?
>> The BCReader? Or perhaps the verifier?
> 
> It's pretty easy to resolve using the rule "assertions should never
> trigger": if the bitcode reader triggers an assertion, it's a bug in
> the bitcode reader.

I asked Chris about this on IRC and he states that he doesn't want this 
in the bitcode reader. If someone wants to verify their types then it 
belongs in the Verifier.

The assertions should probably stay as they are, I don't see any benefit 
to removing them. It turns out that you can construct such illegal types 
even with the assertions we have. Consider:

-- a.ll --
%ty = type opaque
%foo = type <4 x %ty>

-- b.ll --
%ty = type label

Upon llvm-link'ing those, you end up with <4 x label> without triggering 
any asserts. Disassembling the resulting .bc file will trigger an assert 
though.

Nick



From nicholas at mxc.ca  Tue Jun 23 21:44:34 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Tue, 23 Jun 2009 21:44:34 -0700
Subject: [LLVMdev] killing vicmp and vfcmp
Message-ID: <4A41AF32.2040106@mxc.ca>

Now that icmp and fcmp have supported returning vectors of i1 for a 
while, I think it's time to remove the vicmp and vfcmp instructions from 
LLVM. The good news is that we've never shipped a release that included 
them so we won't be providing auto-upgrade support.

There is some existing backend support for vicmp and vfcmp that looks 
different from what icmp and fcmp do. If this actually matters to you, 
please port the bits you need over to icmp/fcmp, or let me know if you 
think you still need vicmp/vfcmp and can't switch within (say) a week.

If I don't hear from anyone within a week then I'll go ahead and rip the 
existing support out.

Thanks!
Nick


From haohui.mai at gmail.com  Tue Jun 23 22:41:03 2009
From: haohui.mai at gmail.com (Mai, Haohui)
Date: Wed, 24 Jun 2009 00:41:03 -0500
Subject: [LLVMdev] Handling SMax(N, N - constInt) in Scalar Evolution pass
In-Reply-To: <4A41AF32.2040106@mxc.ca>
References: <4A41AF32.2040106@mxc.ca>
Message-ID: <1245822063.3929.44.camel@haohui-laptop>

Hi all,

I'm working on a project which tries to prove an access to an array is
safe. For example,

int foo(int s) {
  int * p = malloc(s * sizeof int);
  ...
  int q = p[s - 2];
}

then the access of p[s - 2] always stays in bound.

I implemented a prototype using the Scalar Evolution pass. Here are the
pseudo-code of the implementation:

  const SCEV * offset = SE->getMinusSCEV(SE->getSCEV(GEP), GEPBase);
  const SCEV * bounds = SE->getSCEV(objSize);
 
  if (SE->getSMaxExpr(offset, bounds) == bounds) {
    ++safeGEPs;
  }

But it turns out that SCEVSMaxExpr does not handle the case of SMax(N,
N-2).

My question is, is there a plan to support something like this, or is it
possible to do some refactoring to enhance the capability of Scalar
Evolution? I notice that Scalar Evolution, Instruction Combining and
Memory Dependence Analysis require sort of evaluating symbolic
expression like this.

For this case SMax(A, B) is equivalent to SMax(A-B,0) + B, instruction
combining handles  sophisticated expressions like (A+B)-B pretty well.
It would be great if Scalar Evolution can support this.

Any comments are appreciated.

Cheers,

Haohui



From nicholas at mxc.ca  Tue Jun 23 22:55:23 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Tue, 23 Jun 2009 22:55:23 -0700
Subject: [LLVMdev] Handling SMax(N,
 N - constInt) in Scalar Evolution pass
In-Reply-To: <1245822063.3929.44.camel@haohui-laptop>
References: <4A41AF32.2040106@mxc.ca> <1245822063.3929.44.camel@haohui-laptop>
Message-ID: <4A41BFCB.50505@mxc.ca>

Mai, Haohui wrote:
> Hi all,
> 
> I'm working on a project which tries to prove an access to an array is
> safe. For example,
> 
> int foo(int s) {
>   int * p = malloc(s * sizeof int);
>   ...
>   int q = p[s - 2];
> }
> 
> then the access of p[s - 2] always stays in bound.
> 
> I implemented a prototype using the Scalar Evolution pass. Here are the
> pseudo-code of the implementation:
> 
>   const SCEV * offset = SE->getMinusSCEV(SE->getSCEV(GEP), GEPBase);
>   const SCEV * bounds = SE->getSCEV(objSize);
>  
>   if (SE->getSMaxExpr(offset, bounds) == bounds) {
>     ++safeGEPs;
>   }
> 
> But it turns out that SCEVSMaxExpr does not handle the case of SMax(N,
> N-2).

Consider 8-bit integers and N = -127. N-1 equals INT_MIN and N-2 then is 
equal to INT_MAX, or 127. In that case, the SMax would equal N-2, not N.

In other cases (like N = 2) the SMax would equal N, not N-2.

Because of this, we cannot reduce this SMax any further. Your suggestion 
that "SMax(A, B) == SMax(A-B, 0) + B" is incorrect.

Nick

> My question is, is there a plan to support something like this, or is it
> possible to do some refactoring to enhance the capability of Scalar
> Evolution? I notice that Scalar Evolution, Instruction Combining and
> Memory Dependence Analysis require sort of evaluating symbolic
> expression like this.
> 
> For this case SMax(A, B) is equivalent to SMax(A-B,0) + B, instruction
> combining handles  sophisticated expressions like (A+B)-B pretty well.
> It would be great if Scalar Evolution can support this.
> 
> Any comments are appreciated.
> 
> Cheers,
> 
> Haohui
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 



From haohui.mai at gmail.com  Tue Jun 23 23:05:34 2009
From: haohui.mai at gmail.com (Mai, Haohui)
Date: Wed, 24 Jun 2009 01:05:34 -0500
Subject: [LLVMdev] Handling SMax(N,
 N - constInt) in Scalar Evolution pass
In-Reply-To: <4A41BFCB.50505@mxc.ca>
References: <4A41AF32.2040106@mxc.ca>
	<1245822063.3929.44.camel@haohui-laptop>  <4A41BFCB.50505@mxc.ca>
Message-ID: <1245823534.3929.54.camel@haohui-laptop>

On Tue, 2009-06-23 at 22:55 -0700, Nick Lewycky wrote:
> Mai, Haohui wrote:
> > Hi all,
> > 
> > I'm working on a project which tries to prove an access to an array is
> > safe. For example,
> > 
> > int foo(int s) {
> >   int * p = malloc(s * sizeof int);
> >   ...
> >   int q = p[s - 2];
> > }
> > 
> > then the access of p[s - 2] always stays in bound.
> > 
> > I implemented a prototype using the Scalar Evolution pass. Here are the
> > pseudo-code of the implementation:
> > 
> >   const SCEV * offset = SE->getMinusSCEV(SE->getSCEV(GEP), GEPBase);
> >   const SCEV * bounds = SE->getSCEV(objSize);
> >  
> >   if (SE->getSMaxExpr(offset, bounds) == bounds) {
> >     ++safeGEPs;
> >   }
> > 
> > But it turns out that SCEVSMaxExpr does not handle the case of SMax(N,
> > N-2).
> 
> Consider 8-bit integers and N = -127. N-1 equals INT_MIN and N-2 then is 
> equal to INT_MAX, or 127. In that case, the SMax would equal N-2, not N.
> 
> In other cases (like N = 2) the SMax would equal N, not N-2.
> 
> Because of this, we cannot reduce this SMax any further. Your suggestion 
> that "SMax(A, B) == SMax(A-B, 0) + B" is incorrect.
> Nick

It seems that there are codes in Scalar Evolution to handle this case.
Many operations in scalar evolution only happen when SCEV can be sign
extended.

> 
> > My question is, is there a plan to support something like this, or is it
> > possible to do some refactoring to enhance the capability of Scalar
> > Evolution? I notice that Scalar Evolution, Instruction Combining and
> > Memory Dependence Analysis require sort of evaluating symbolic
> > expression like this.
> > 
> > For this case SMax(A, B) is equivalent to SMax(A-B,0) + B, instruction
> > combining handles  sophisticated expressions like (A+B)-B pretty well.
> > It would be great if Scalar Evolution can support this.
> > 
> > Any comments are appreciated.
> > 
> > Cheers,
> > 
> > Haohui
> > 
> > _______________________________________________
> > 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 haohui.mai at gmail.com  Tue Jun 23 23:08:10 2009
From: haohui.mai at gmail.com (Mai, Haohui)
Date: Wed, 24 Jun 2009 01:08:10 -0500
Subject: [LLVMdev] Handling SMax(N,
 N - constInt) in Scalar Evolution pass
In-Reply-To: <1245823534.3929.54.camel@haohui-laptop>
References: <4A41AF32.2040106@mxc.ca>
	<1245822063.3929.44.camel@haohui-laptop>  <4A41BFCB.50505@mxc.ca>
	<1245823534.3929.54.camel@haohui-laptop>
Message-ID: <1245823690.3929.57.camel@haohui-laptop>

Nick,

It might be a little bit difficult to handle SMax correctly. But is it
possible to reduce A+(-A) to 0 in SAddExpr?

Haohui


On Wed, 2009-06-24 at 01:05 -0500, Mai, Haohui wrote:
> On Tue, 2009-06-23 at 22:55 -0700, Nick Lewycky wrote:
> > Mai, Haohui wrote:
> > > Hi all,
> > > 
> > > I'm working on a project which tries to prove an access to an array is
> > > safe. For example,
> > > 
> > > int foo(int s) {
> > >   int * p = malloc(s * sizeof int);
> > >   ...
> > >   int q = p[s - 2];
> > > }
> > > 
> > > then the access of p[s - 2] always stays in bound.
> > > 
> > > I implemented a prototype using the Scalar Evolution pass. Here are the
> > > pseudo-code of the implementation:
> > > 
> > >   const SCEV * offset = SE->getMinusSCEV(SE->getSCEV(GEP), GEPBase);
> > >   const SCEV * bounds = SE->getSCEV(objSize);
> > >  
> > >   if (SE->getSMaxExpr(offset, bounds) == bounds) {
> > >     ++safeGEPs;
> > >   }
> > > 
> > > But it turns out that SCEVSMaxExpr does not handle the case of SMax(N,
> > > N-2).
> > 
> > Consider 8-bit integers and N = -127. N-1 equals INT_MIN and N-2 then is 
> > equal to INT_MAX, or 127. In that case, the SMax would equal N-2, not N.
> > 
> > In other cases (like N = 2) the SMax would equal N, not N-2.
> > 
> > Because of this, we cannot reduce this SMax any further. Your suggestion 
> > that "SMax(A, B) == SMax(A-B, 0) + B" is incorrect.
> > Nick
> 
> It seems that there are codes in Scalar Evolution to handle this case.
> Many operations in scalar evolution only happen when SCEV can be sign
> extended.
> 
> > 
> > > My question is, is there a plan to support something like this, or is it
> > > possible to do some refactoring to enhance the capability of Scalar
> > > Evolution? I notice that Scalar Evolution, Instruction Combining and
> > > Memory Dependence Analysis require sort of evaluating symbolic
> > > expression like this.
> > > 
> > > For this case SMax(A, B) is equivalent to SMax(A-B,0) + B, instruction
> > > combining handles  sophisticated expressions like (A+B)-B pretty well.
> > > It would be great if Scalar Evolution can support this.
> > > 
> > > Any comments are appreciated.
> > > 
> > > Cheers,
> > > 
> > > Haohui
> > > 
> > > _______________________________________________
> > > 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  Tue Jun 23 23:16:05 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Tue, 23 Jun 2009 23:16:05 -0700
Subject: [LLVMdev] Handling SMax(N,
 N - constInt) in Scalar Evolution pass
In-Reply-To: <1245823690.3929.57.camel@haohui-laptop>
References: <4A41AF32.2040106@mxc.ca>	<1245822063.3929.44.camel@haohui-laptop>
	<4A41BFCB.50505@mxc.ca>	<1245823534.3929.54.camel@haohui-laptop>
	<1245823690.3929.57.camel@haohui-laptop>
Message-ID: <4A41C4A5.3020904@mxc.ca>

Mai, Haohui wrote:
> Nick,
> 
> It might be a little bit difficult to handle SMax correctly. But is it
> possible to reduce A+(-A) to 0 in SAddExpr?

Yes, it should already do that. Here's a quick test I wrote up:

   $ cat x.ll
   define i8 @test(i8 %x) {
     %neg = sub i8 0, %x
     %sum = add i8 %x, %neg
     ret i8 %sum
   }
   $ llvm-as < x.ll | opt -analyze -scalar-evolution -disable-output
   Printing analysis 'Scalar Evolution Analysis' for function 'test':
   Classifying expressions for: test
           %neg = sub i8 0, %x             ; <i8> [#uses=1]
     -->  (-1 * %x)
           %sum = add i8 %x, %neg          ; <i8> [#uses=1]
     -->  0
   Determining loop execution counts for: test

You'll note that %sum is deduced to be 0 and not (%x + (-1 * %x)) which 
indicates that this optimization is working correctly. If you have a 
more complicated case where it isn't, feel free to file a bug and cc me.

Nick

> On Wed, 2009-06-24 at 01:05 -0500, Mai, Haohui wrote:
>> On Tue, 2009-06-23 at 22:55 -0700, Nick Lewycky wrote:
>>> Mai, Haohui wrote:
>>>> Hi all,
>>>>
>>>> I'm working on a project which tries to prove an access to an array is
>>>> safe. For example,
>>>>
>>>> int foo(int s) {
>>>>   int * p = malloc(s * sizeof int);
>>>>   ...
>>>>   int q = p[s - 2];
>>>> }
>>>>
>>>> then the access of p[s - 2] always stays in bound.
>>>>
>>>> I implemented a prototype using the Scalar Evolution pass. Here are the
>>>> pseudo-code of the implementation:
>>>>
>>>>   const SCEV * offset = SE->getMinusSCEV(SE->getSCEV(GEP), GEPBase);
>>>>   const SCEV * bounds = SE->getSCEV(objSize);
>>>>  
>>>>   if (SE->getSMaxExpr(offset, bounds) == bounds) {
>>>>     ++safeGEPs;
>>>>   }
>>>>
>>>> But it turns out that SCEVSMaxExpr does not handle the case of SMax(N,
>>>> N-2).
>>> Consider 8-bit integers and N = -127. N-1 equals INT_MIN and N-2 then is 
>>> equal to INT_MAX, or 127. In that case, the SMax would equal N-2, not N.
>>>
>>> In other cases (like N = 2) the SMax would equal N, not N-2.
>>>
>>> Because of this, we cannot reduce this SMax any further. Your suggestion 
>>> that "SMax(A, B) == SMax(A-B, 0) + B" is incorrect.
>>> Nick
>> It seems that there are codes in Scalar Evolution to handle this case.
>> Many operations in scalar evolution only happen when SCEV can be sign
>> extended.
>>
>>>> My question is, is there a plan to support something like this, or is it
>>>> possible to do some refactoring to enhance the capability of Scalar
>>>> Evolution? I notice that Scalar Evolution, Instruction Combining and
>>>> Memory Dependence Analysis require sort of evaluating symbolic
>>>> expression like this.
>>>>
>>>> For this case SMax(A, B) is equivalent to SMax(A-B,0) + B, instruction
>>>> combining handles  sophisticated expressions like (A+B)-B pretty well.
>>>> It would be great if Scalar Evolution can support this.
>>>>
>>>> Any comments are appreciated.
>>>>
>>>> Cheers,
>>>>
>>>> Haohui
>>>>
>>>> _______________________________________________
>>>> 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
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 



From eric at brouhaha.com  Wed Jun 24 00:01:08 2009
From: eric at brouhaha.com (Eric Smith)
Date: Wed, 24 Jun 2009 00:01:08 -0700
Subject: [LLVMdev] Garbage collection implementation
Message-ID: <4A41CF34.5020809@brouhaha.com>

Jon Harrop wrote:
 > The simplest way is surely to reuse HLVM because it provides 
everything you
 > need and is even written in the right language! ;-)

Is there a web page with HLVM docs?  There's a README.txt in the 
subversion repository:

    https://llvm.org/svn/llvm-project/hlvm/trunk/README.txt

which says:

    HLVM comes with documentation in HTML format. These are provided in 
the docs
    directory. Please visit http://llvm.org/docs/hlvm/ to get an index 
of the
    documentation that is available.

but unfortunately that URL yields a 404.

While I could check the docs out of subversion myself (assuming they're 
actually there, which I haven't verified), putting the docs online for 
easy access would be much more conducive to attracting users and or 
developers to HLVM.

Eric



From eric at brouhaha.com  Wed Jun 24 00:10:42 2009
From: eric at brouhaha.com (Eric Smith)
Date: Wed, 24 Jun 2009 00:10:42 -0700
Subject: [LLVMdev] making trampolines more portable
Message-ID: <4A41D172.3000403@brouhaha.com>

Duncan Sands wrote:
 > is it important for you to have portable bitcode (i.e. the trampoline
 > size as some kind of symbolic constant, maybe via a global or an
 > intrinsic) that works on all targets or would it be enough to have the
 > LLVM info for the target expose the trampoline size, so when generating
 > IR for a target X you would query the method for target X and if it
 > returns "12 bytes" you would output an alloca of 12 bytes.

I'd prefer the former, but the latter is clearly much better than
having to guess.

 > right now if you want to call external functions
 > (for example) you need to know target details in order to generate IR
 > that conforms to the target ABI.  Just pointing out that it is hard to
 > generate target independent bitcode that does non-trivial things.

Hmm...  sounds like my intention to use LLVM bitcode as a portable
intermediate code is doomed, then.  I had hoped that the "V" in LLVM
gave me more target-independence than that.  I wouldn't necessarily
have expected this to work for entirely arbitrary ABIs, but I'd hoped
that it would have at least abstracted away the target calling conventions
for C functions.

Best regards,
Eric



From eric at brouhaha.com  Wed Jun 24 00:13:09 2009
From: eric at brouhaha.com (Eric Smith)
Date: Wed, 24 Jun 2009 00:13:09 -0700
Subject: [LLVMdev] making trampolines more portable
Message-ID: <4A41D205.7020804@brouhaha.com>

Eli Friedman wrote:
 > I didn't say we wouldn't accept a patch.  It's just that up until now
 > nobody has particularly cared because trampolines aren't used very
 > much.

Fair enough.  If I get to the point where I understand how to implement it
cleanly, I'll submit a patch.

Best regards,
Eric



From baldrick at free.fr  Wed Jun 24 00:27:44 2009
From: baldrick at free.fr (Duncan Sands)
Date: Wed, 24 Jun 2009 09:27:44 +0200
Subject: [LLVMdev] How to add a trivial LLVM intrinsic
In-Reply-To: <005301c9f447$7ddc1340$799439c0$@wisc.edu>
References: <005301c9f447$7ddc1340$799439c0$@wisc.edu>
Message-ID: <4A41D570.5000009@free.fr>

Hi,

> After invoking:
> llvm-gcc -g test.c -o test.native
> -----------------
> The compiler returns:
> cc1: Function.cpp:323: unsigned int llvm::Function::getIntrinsicID(bool)
> const: Assertion `noAssert && "Invalid LLVM intrinsic name"' failed.
> test.c:24: internal compiler error: Aborted

did you rebuild llvm-gcc after building llvm with your new intrinsic
defined?

Ciao,

Duncan.


From eric at brouhaha.com  Wed Jun 24 00:29:06 2009
From: eric at brouhaha.com (Eric Smith)
Date: Wed, 24 Jun 2009 00:29:06 -0700
Subject: [LLVMdev] Garbage Collection Project
Message-ID: <4A41D5C2.90102@brouhaha.com>

Talin wrote:
 > A while back there was a discussion thread about whether an accurate,
 > concurrent garbage collector could be "generic" in the sense of being
 > able to support multiple different languages efficiently. After having
 > done some work on this, I now believe that this is the case

Very cool!  I haven't worked on a system with good concurrent garbage
collection since using the Intel iAPX-432 back in the mid-1980s.  It
used Dijkstra's concurrent garbage collection algorithm, which is a
mark-sweep collector with three colors.  The 432 architecture inherently
divided the representation of all objects into two segments, of which
one could only contain access descriptors (pointers), and the other
could only contain date other than access descriptors.  This made it
quite easy to trace all of the live objects starting from a small set of
known root objects.  This has also been used in LISP systems, and I've
heard that it has been used in some experimental JVMs, but I wasn't
sure that precise concurrent garbage collection could be implemented
efficiently for languages like C++ without imposing significant
restrictions on the usage of the language, so I thought I'd have to get
by with conservative collectors.

Best regards,
Eric



From marc.reynolds at orange.fr  Wed Jun 24 00:47:19 2009
From: marc.reynolds at orange.fr (Marc B. Reynolds)
Date: Wed, 24 Jun 2009 09:47:19 +0200
Subject: [LLVMdev] Garbage collection implementation
In-Reply-To: <4A41CF34.5020809@brouhaha.com>
Message-ID: <61F89B3322D945B8A8373B382CEC363F@croaker>


Two difference projects with same name. Try:

http://forge.ocamlcore.org/projects/hlvm


-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Eric Smith
Sent: Wednesday, June 24, 2009 9:01 AM
To: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] Garbage collection implementation



Jon Harrop wrote:
 > The simplest way is surely to reuse HLVM because it provides 
everything you
 > need and is even written in the right language! ;-)

Is there a web page with HLVM docs?  There's a README.txt in the 
subversion repository:

    https://llvm.org/svn/llvm-project/hlvm/trunk/README.txt

which says:

    HLVM comes with documentation in HTML format. These are provided in 
the docs
    directory. Please visit http://llvm.org/docs/hlvm/ to get an index 
of the
    documentation that is available.

but unfortunately that URL yields a 404.

While I could check the docs out of subversion myself (assuming they're 
actually there, which I haven't verified), putting the docs online for 
easy access would be much more conducive to attracting users and or 
developers to HLVM.

Eric

_______________________________________________
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 Jun 24 00:47:30 2009
From: baldrick at free.fr (Duncan Sands)
Date: Wed, 24 Jun 2009 09:47:30 +0200
Subject: [LLVMdev] killing vicmp and vfcmp
In-Reply-To: <4A41AF32.2040106@mxc.ca>
References: <4A41AF32.2040106@mxc.ca>
Message-ID: <4A41DA12.90106@free.fr>

Hi Nick,

> Now that icmp and fcmp have supported returning vectors of i1 for a 
> while,

the code generators don't know how to codegen vectors of i1, so does
this actually work?

Ciao,

Duncan.


From baldrick at free.fr  Wed Jun 24 00:53:25 2009
From: baldrick at free.fr (Duncan Sands)
Date: Wed, 24 Jun 2009 09:53:25 +0200
Subject: [LLVMdev] making trampolines more portable
In-Reply-To: <4A41D172.3000403@brouhaha.com>
References: <4A41D172.3000403@brouhaha.com>
Message-ID: <4A41DB75.9000706@free.fr>

Hi Eric,

> Hmm...  sounds like my intention to use LLVM bitcode as a portable
> intermediate code is doomed, then.  I had hoped that the "V" in LLVM
> gave me more target-independence than that.  I wouldn't necessarily
> have expected this to work for entirely arbitrary ABIs, but I'd hoped
> that it would have at least abstracted away the target calling conventions
> for C functions.

for some ABI's the way a parameter is passed can depend on C type
information that there is no good way to represent in LLVM.  This
is why (for the moment) front-ends are required to take care of
producing LLVM function declarations that conform with the ABI.
There is a plan to have a generic ABI library which makes it easy
for front-ends to do this.

Ciao,

Duncan.


From baldrick at free.fr  Wed Jun 24 00:54:31 2009
From: baldrick at free.fr (Duncan Sands)
Date: Wed, 24 Jun 2009 09:54:31 +0200
Subject: [LLVMdev] lli aborts on arm QEMU
In-Reply-To: <20090623192606.0D42BBE407E@ws1-9.us4.outblaze.com>
References: <20090623192606.0D42BBE407E@ws1-9.us4.outblaze.com>
Message-ID: <4A41DBB7.3030303@free.fr>

hannibal hannibal wrote:
> I get the following error when I try to run arm lli on QEMU:
> 
> lli: llvm-arm/src/llvm/include/llvm/ADT/ilist.h:197: typename bidirectional_iterator<NodeTy, int>::reference llvm::ilist_iterator<NodeTy>::operator*() const [with NodeTy = llvm::RecyclerStruct]: Assertion `Traits::getNext(NodePtr) != 0 && "Dereferencing end()!"' failed.
> 0   lli 0x006abbfc
> Stack dump:
> 0.	Program arguments: ./lli hello2.bc 
> 1.	Running pass 'ARM Instruction Selection' on function '@main'
> Aborted.
> 
> 
> Is it a bug or I am doing something stupid?

It sounds like a bug.  However ARM is moving fast at the moment, so
you might want to try again in a few days time before opening a bug
report.

Ciao,

Duncan.


From pertti.kellomaki at tut.fi  Wed Jun 24 01:24:55 2009
From: pertti.kellomaki at tut.fi (=?ISO-8859-1?Q?Pertti_Kellom=E4ki?=)
Date: Wed, 24 Jun 2009 11:24:55 +0300
Subject: [LLVMdev] Garbage Collection Project
In-Reply-To: <4A41D5C2.90102@brouhaha.com>
References: <4A41D5C2.90102@brouhaha.com>
Message-ID: <4A41E2D7.5090504@tut.fi>

Eric Smith wrote:
> I wasn't
> sure that precise concurrent garbage collection could be implemented
> efficiently for languages like C++ without imposing significant
> restrictions on the usage of the language,

The use of destructors to do all kinds of clean up stuff is a
major source of headaches when incorporating garbage collection to
C++. I don't know if there has been significant progress on this
front since I briefly followed it a few years ago.
-- 
Pertti


From baldrick at free.fr  Wed Jun 24 01:56:04 2009
From: baldrick at free.fr (Duncan Sands)
Date: Wed, 24 Jun 2009 10:56:04 +0200
Subject: [LLVMdev] Undocumented API changes
In-Reply-To: <4A393EC4.80205@dcs.gla.ac.uk>
References: <d17b77a40906170910h607175bcm6d51a23e0e11db6c@mail.gmail.com>	<4A391DCB.8070307@assumetheposition.nl>	<24361044-96E1-4490-A7B6-31A4E097CB46@apple.com>
	<4A393EC4.80205@dcs.gla.ac.uk>
Message-ID: <4A41EA24.4010200@free.fr>

Hi Mark,

> Why are there so many undocumented (and as I far I can see) unnecessary 
> API changes?

these can now be documented in docs/ReleaseNotes-2.6.html.

Ciao,

Duncan.

> 
> Recently there has been:
> 
> 1.
> For JIT applications, please include llvm/Target/TargetSelect.h and
> call the llvm::InitializeNativeTarget() function before creating an EE.
> 
> 2.
> The major CHANGE is:  the JIT will no longer be safe for executing
> threaded applications without first invoking llvm_start_multithreaded(). 
>   Please begin to update your client applications now if this affects 
> you, as I will be throwing the switch in SVN sooner rather than later.
> 
> 3.
> The change you should make: every call to addPassesToEmitFile,
> addPassesToEmitFileFinish, addPassesToEmitMachineCode, or
> addCommonCodeGenPasses should pass an optimization level enum rather
> than true / false for "Fast". The enum is in
> llvm/Target/TargetMachine.h:
> 
> namespace CodeGenOpt {
>    enum Level {
>      Default,
>      None,
>      Aggressive
>    };
> }
> 
> 4.
> The LLVM IR opcodes Add, Sub, and Mul have been each split into two. 
> Add, Sub, and Mul now only handle integer types, and three new opcodes, 
> FAdd, FSub, and FMul now handle floating-point types.
> 
> And that's just in a few days!
> 
> I recently tried to build my compiler-generator with the svn-head 
> version of llvm.
> No chance.
> It wouldn't build, thanks to (3) above.
> Once I got it to build, it crashed.
> It all works just fine with 2.5.
> 
> I spent a lot of time and effort, getting things to work, first with 
> 2.4, then with 2.5 (The changes in the API between 2.4 and 2.5 were more 
> than I would have liked, but mainly renaming and caught by the compiler).
> 
> Remember, its not just gcc-llvm and clang that use llvm.
> 
> So please treat the API with respect.
> Don't change it often, and document EACH and EVERY change.
> 
> PS.
> 
> Change (1) above seems to be pointless.
> Why can't the code to create the EE, just call 
> llvm::InitializeNativeTarget()?
> 
> Mark.
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



From ihusar at fit.vutbr.cz  Wed Jun 24 05:47:10 2009
From: ihusar at fit.vutbr.cz (ihusar)
Date: Wed, 24 Jun 2009 14:47:10 +0200
Subject: [LLVMdev] LLVM frontend supporting arbitrary bit-width integral
 datatypes
In-Reply-To: <4A2834A8.2080402@tut.fi>
References: <op.uuwe38tn0lgsd9@localhost.localdomain> <4A2834A8.2080402@tut.fi>
Message-ID: <op.uv04gua50lgsd9@localhost.localdomain>

On Thu, 04 Jun 2009 22:55:04 +0200, Pertti Kellomäki <pertti.kellomaki at tut.fi> wrote:

> Hi Adam,
>
> John is right, the TCE stuff would be useful for you. Our
> compiler targets a processor template that the designer can
> populate pretty freely. The compiler then reads the architecture
> description and creates an LLVM backend on the fly.
>
> Please don't hesitate to get in touch with us if you have
> questions.




Hello,

 thank you for your answers, in fact, the TCE project is quite similar to our project Lissom (http://www.fit.vutbr.cz/research/view_product.php.en?id=52&notitle=1), I will take a closer look at it.

One problem, I was trying to solve was, that I need to declare variables of let's say 5-bit width like  'i5 var',
the maximal bit-width may be limited to 64 bits. I need such variables to represent instruction's operands,
example is at the end this message.

For now, I did not find any usable compiler frontend.

First attempt was quite old Valen-C based on SUIF compiler which requires unavailable version of
SUIF and would be hard to make work.
Second attempt was SpecC reference compiler - as most of high-level language synthetizers, turns
arbitrary bit-width integers into C++ templates which makes it unusable.
Then few other attempts, but not much luck.

The conclusion is, that I will need to modify some compiler frontend by my own, propably the clang.
Please, if you have some info afout this or if anyone has already tried such thing, could you write it here?
Also, is there anything I should be aware of when modifing the clang? Are there some passes, that are 
made only for the standard C datatypes?
Stuff like sizeof() and C pointer arithmetics can be forbidden integers which bit width is not divisible by 8.


Thank you
  Adam


(I am posting this both to the llvmdev and clangdev, sry for possible spamming.)


Example of why do I need arbitrary bit-width integers: 

I can extract from our architecture description language ISAC code, that for each instruction tells what it
does:

Syntax:

MIPS instrucion ADDDI

"ADDI" reg(0) "," reg(1) "," imm(2)


Semantics:

unsigned int gpregs[32];

void instr_direct_rri$op_addi$imm16$()
{
int op_arithm_imm = 0x08; {
int rt = 1; {
int rs = 28; {
short imm16 = imm_i16(2); //--- intrinsics, represents instruction's immediate operand
{
{

int simm = ((int)(imm16) << (32 - (16))) >> (32 - (16));


switch (op_arithm_imm)
{
//....

case 0x08:
case 0x09:
{if (rt != 0) gpregs[(rt)] = (( (((rs) != 0)?gpregs[(rs)]:0) ) + simm);};
break;

case 0x0A:
{if (rt != 0) gpregs[(rt)] = (( (((rs) != 0)?gpregs[(rs)]:0) ) < simm);};
break;

//....

}
}}}}}
}


Compile it with LLVM or any other compiler and get optimized code:


; ModuleID = 't2.c'
target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128"
target triple = "x86_64-unknown-linux-gnu"
@gpregs = common global [32 x i32] zeroinitializer, align 4             ; <[32 x i32]*> [#uses=2]

define void @"instr_direct_rri$op_addi$imm16$"() nounwind {
entry:
        %tmp = tail call i16 @llvm.immread.i16.i32(i32 2) nounwind              ; <i16> [#uses=1]
        %shr = sext i16 %tmp to i32             ; <i32> [#uses=1]
        %tmp10 = load i32* getelementptr ([32 x i32]* @gpregs, i32 0, i64 28)           ; <i32> [#uses=1]
        %add = add i32 %tmp10, %shr             ; <i32> [#uses=1]
        store i32 %add, i32* getelementptr ([32 x i32]* @gpregs, i32 0, i64 1)
        ret void
}


This I can quite easily transform to instruction selection rule:

set(reg, add(reg, sext(32, imm)))

which is then used by compiler backend generator, so the code selector can then use instruction ADDI.

The problem is, that the only supported types now are i8, i16 and i32 (and floating in the future).
If the processor designer would like to have 12-bit operand, I need to turn it into 16-bit and
then the compiler would generate useless code for extension/truncation and 
extracted code selection rule would not be correct.








From eli.friedman at gmail.com  Wed Jun 24 05:59:46 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Wed, 24 Jun 2009 05:59:46 -0700
Subject: [LLVMdev] LLVM frontend supporting arbitrary bit-width integral
	datatypes
In-Reply-To: <op.uv04gua50lgsd9@localhost.localdomain>
References: <op.uuwe38tn0lgsd9@localhost.localdomain> <4A2834A8.2080402@tut.fi>
	<op.uv04gua50lgsd9@localhost.localdomain>
Message-ID: <f5aa3e9b0906240559v5f57cca8n4168db232d0f7ee6@mail.gmail.com>

On Wed, Jun 24, 2009 at 5:47 AM, ihusar<ihusar at fit.vutbr.cz> wrote:
> The conclusion is, that I will need to modify some compiler frontend by my own, propably the clang.
> Please, if you have some info afout this or if anyone has already tried such thing, could you write it here?
> Also, is there anything I should be aware of when modifing the clang? Are there some passes, that are
> made only for the standard C datatypes?
> Stuff like sizeof() and C pointer arithmetics can be forbidden integers which bit width is not divisible by 8.

clang already has some code for types like this, but there isn't any
way to declare such a type yet.  Patches welcome, or I'll probably get
around to writing it at some point.

(If you have any additional questions about that, please direct them
to cfe-dev only.)

-Eli


From baldrick at free.fr  Wed Jun 24 06:23:04 2009
From: baldrick at free.fr (Duncan Sands)
Date: Wed, 24 Jun 2009 15:23:04 +0200
Subject: [LLVMdev] LLVM frontend supporting arbitrary bit-width integral
 datatypes
In-Reply-To: <op.uv04gua50lgsd9@localhost.localdomain>
References: <op.uuwe38tn0lgsd9@localhost.localdomain> <4A2834A8.2080402@tut.fi>
	<op.uv04gua50lgsd9@localhost.localdomain>
Message-ID: <4A4228B8.8040005@free.fr>

Hi Adam,

> One problem, I was trying to solve was, that I need to declare variables of let's say 5-bit width like  'i5 var',
> the maximal bit-width may be limited to 64 bits. I need such variables to represent instruction's operands,
> example is at the end this message.

any standard compliant C compiler supports i5, believe it or not.

Try this:

#include <stdio.h>

struct i3 { int i:3; };

int main(void) {
   struct i3 A, B, C;

   A.i = 2;
   B.i = 3;
   C.i = A.i + B.i;
   printf("%d + %d = %d\n", A.i, B.i, C.i);
   return 0;
}

I get:
2 + 3 = -3
which is correct for i3 arithmetic!
There might be some problems with signed vs unsigned bitfields,
depending on the compiler.

Ciao,

Duncan.


From ihusar at fit.vutbr.cz  Wed Jun 24 08:05:10 2009
From: ihusar at fit.vutbr.cz (ihusar)
Date: Wed, 24 Jun 2009 17:05:10 +0200
Subject: [LLVMdev] LLVM frontend supporting arbitrary bit-width integral
 datatypes, semantics extraction
In-Reply-To: <4A4228B8.8040005@free.fr>
References: <op.uuwe38tn0lgsd9@localhost.localdomain>
	<4A2834A8.2080402@tut.fi> <op.uv04gua50lgsd9@localhost.localdomain>
	<4A4228B8.8040005@free.fr>
Message-ID: <op.uv1auww70lgsd9@localhost.localdomain>

> Hi Adam,
> any standard compliant C compiler supports i5, believe it or not.
>
> Try this:
>
> #include <stdio.h>
>
> struct i3 { int i:3; };
...
> Ciao,
>
> Duncan.


Hi,

  i knew about this feature and i tried this already, but thank you very much for reminding it to me.
I just needed to make few changes to the generated code and everything works as i expected!
I was doing something wrong before, because the compiler has generated some additional code that would make 
problems when creating instruction selection rules.

If somebody would be having similar problems, I am putting fixed example here:

unsigned int gpregs[32];

struct i16 { int a:16;};

void instr_direct_rri()
{

  int op_arithm_imm = 0x08; {
  int rt = 1; {
  int rs = 28; {
  struct i16 imm16; imm16.a = immread_i16(0); {{ //immread_i16 is a special builtin with return type i16

  int simm = ((int)(imm16.a) << (32 - (16))) >> (32 - (16));

  switch (op_arithm_imm)
  {
     case 0x08:
     case 0x09:
       {if (rt != 0) gpregs[(rt)] = (( (((rs) != 0)?gpregs[(rs)]:0) ) + simm);};
       break;

     case 0x0A:
       {if (rt != 0) gpregs[(rt)] = (( (((rs) != 0)?gpregs[(rs)]:0) ) < simm);};
       break;

  }  

}}}}}

}    

After  clang-cc -O3 -std=c99 tt.c -emit-llvm -o -  I get:


%tmp = tail call i16 @llvm.immread.i16.i32(i32 0) nounwind              ; <i16> [#uses=1]
%conv = sext i16 %tmp to i32            ; <i32> [#uses=1]
%tmp14 = load i32* getelementptr ([32 x i32]* @gpregs, i32 0, i64 28)           ; <i32> [#uses=1]
%add = add i32 %tmp14, %conv            ; <i32> [#uses=1]
store i32 %add, i32* getelementptr ([32 x i32]* @gpregs, i32 0, i64 1)
ret void


that represents exactly what i needed:

set(reg(1), 
  add(
    reg(28), 
    sext(32, imm(0))
  )
)

Thanks a lot
  Adam


On Wed, 24 Jun 2009 15:23:04 +0200, Duncan Sands <baldrick at free.fr> wrote:

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





From deeppatel1987 at gmail.com  Wed Jun 24 08:08:17 2009
From: deeppatel1987 at gmail.com (Sandeep Patel)
Date: Wed, 24 Jun 2009 08:08:17 -0700
Subject: [LLVMdev] make check where host != target
Message-ID: <305d6f60906240808v482a9442kd6ce7fa93f4046d3@mail.gmail.com>

Is make check supposed to work in cases where host != target? I'm
seeing a ton of problems where the makefiles are testing $(OS) and
trying to test the properties of the target OS, not the host OS.

deep


From ihusar at fit.vutbr.cz  Wed Jun 24 08:32:29 2009
From: ihusar at fit.vutbr.cz (ihusar)
Date: Wed, 24 Jun 2009 17:32:29 +0200
Subject: [LLVMdev] Replacing instruction in LLVM IR by an intrinsics
Message-ID: <op.uv1b4f2c0lgsd9@localhost.localdomain>

Hi everyone,

  I am trying to write a pass, that finds some instructions and replaces them with my intrinsics,
but I am having problem understanding, how this should be done. 

Let's say I have this instruction:

 %tmp14 = load i32* getelementptr ([32 x i32]* @gpregs, i32 0, i64 28) 


and i need to read the load's operands and replace it by let's say:

 %tmp14 = call i32 @llvm.regread_i32.i32(i32 0, i32 1)


Here is what I have:

  //for each instruction of a function
  for (inst_iterator I = inst_begin(F), E = inst_end(F); I != E; ++I)
  {
	Instruction* i = &(*I);
		
	//if this is a load
	if (isa<LoadInst>(i))
	{
		//now i need to create an instruction that represents a call to a intrinsic
		Function* FIntr = Intrinsic::getDeclaration(&M, Intrinsic::regread_i32); 

		// here it fails: void llvm::CallInst::init(llvm::Value*): 
		//Assertion `FTy->getNumParams() == 0 && "Calling a function with bad signature"' failed.
		Instruction* Instr = CallInst::Create(FIntr); 

		//do some stuff with the operands

		//and replace it
		ReplaceInstWithInst(i, Instr);
	}
}  


Intrinsic regread_i32 is defined in Intrinsics.td as follows:

//represents register value read, as arguments takes 1) register class number (determined from the acessed variable, here 'regs') and 2) register operand index (not important now)
def int_regread_i32          : Intrinsic<[llvm_i32_ty], [llvm_i32_ty, llvm_i32_ty], [IntrNoMem]>;


The problem is, that I have not found yet, how to correctly create an intrinsic instruction and
how do I access and set operands. Is there some documentation, how is the LLVM IR API designed?
Or, has someone already tried to solve similar problem? (I am already trying to learn from the source code how it works, 
but I thought that asking you would be faster:)

Thank you
  Adam


btw.: Is there a way how to search archived messages from this mailing list? Google with site:lists.cs.uiuc.edu
does not work very much.


From haohui.mai at gmail.com  Wed Jun 24 08:55:26 2009
From: haohui.mai at gmail.com (Mai, Haohui)
Date: Wed, 24 Jun 2009 10:55:26 -0500
Subject: [LLVMdev] Handling SMax(N,
 N - constInt) in Scalar Evolution pass
In-Reply-To: <4A41C4A5.3020904@mxc.ca>
References: <4A41AF32.2040106@mxc.ca>
	<1245822063.3929.44.camel@haohui-laptop> <4A41BFCB.50505@mxc.ca>
	<1245823534.3929.54.camel@haohui-laptop>
	<1245823690.3929.57.camel@haohui-laptop>  <4A41C4A5.3020904@mxc.ca>
Message-ID: <1245858926.3900.2.camel@haohui-laptop>

Nick,

It works pretty cool.

Thank you.

Haohui

On Tue, 2009-06-23 at 23:16 -0700, Nick Lewycky wrote:
> Mai, Haohui wrote:
> > Nick,
> > 
> > It might be a little bit difficult to handle SMax correctly. But is it
> > possible to reduce A+(-A) to 0 in SAddExpr?
> 
> Yes, it should already do that. Here's a quick test I wrote up:
> 
>    $ cat x.ll
>    define i8 @test(i8 %x) {
>      %neg = sub i8 0, %x
>      %sum = add i8 %x, %neg
>      ret i8 %sum
>    }
>    $ llvm-as < x.ll | opt -analyze -scalar-evolution -disable-output
>    Printing analysis 'Scalar Evolution Analysis' for function 'test':
>    Classifying expressions for: test
>            %neg = sub i8 0, %x             ; <i8> [#uses=1]
>      -->  (-1 * %x)
>            %sum = add i8 %x, %neg          ; <i8> [#uses=1]
>      -->  0
>    Determining loop execution counts for: test
> 
> You'll note that %sum is deduced to be 0 and not (%x + (-1 * %x)) which 
> indicates that this optimization is working correctly. If you have a 
> more complicated case where it isn't, feel free to file a bug and cc me.
> 
> Nick
> 
> > On Wed, 2009-06-24 at 01:05 -0500, Mai, Haohui wrote:
> >> On Tue, 2009-06-23 at 22:55 -0700, Nick Lewycky wrote:
> >>> Mai, Haohui wrote:
> >>>> Hi all,
> >>>>
> >>>> I'm working on a project which tries to prove an access to an array is
> >>>> safe. For example,
> >>>>
> >>>> int foo(int s) {
> >>>>   int * p = malloc(s * sizeof int);
> >>>>   ...
> >>>>   int q = p[s - 2];
> >>>> }
> >>>>
> >>>> then the access of p[s - 2] always stays in bound.
> >>>>
> >>>> I implemented a prototype using the Scalar Evolution pass. Here are the
> >>>> pseudo-code of the implementation:
> >>>>
> >>>>   const SCEV * offset = SE->getMinusSCEV(SE->getSCEV(GEP), GEPBase);
> >>>>   const SCEV * bounds = SE->getSCEV(objSize);
> >>>>  
> >>>>   if (SE->getSMaxExpr(offset, bounds) == bounds) {
> >>>>     ++safeGEPs;
> >>>>   }
> >>>>
> >>>> But it turns out that SCEVSMaxExpr does not handle the case of SMax(N,
> >>>> N-2).
> >>> Consider 8-bit integers and N = -127. N-1 equals INT_MIN and N-2 then is 
> >>> equal to INT_MAX, or 127. In that case, the SMax would equal N-2, not N.
> >>>
> >>> In other cases (like N = 2) the SMax would equal N, not N-2.
> >>>
> >>> Because of this, we cannot reduce this SMax any further. Your suggestion 
> >>> that "SMax(A, B) == SMax(A-B, 0) + B" is incorrect.
> >>> Nick
> >> It seems that there are codes in Scalar Evolution to handle this case.
> >> Many operations in scalar evolution only happen when SCEV can be sign
> >> extended.
> >>
> >>>> My question is, is there a plan to support something like this, or is it
> >>>> possible to do some refactoring to enhance the capability of Scalar
> >>>> Evolution? I notice that Scalar Evolution, Instruction Combining and
> >>>> Memory Dependence Analysis require sort of evaluating symbolic
> >>>> expression like this.
> >>>>
> >>>> For this case SMax(A, B) is equivalent to SMax(A-B,0) + B, instruction
> >>>> combining handles  sophisticated expressions like (A+B)-B pretty well.
> >>>> It would be great if Scalar Evolution can support this.
> >>>>
> >>>> Any comments are appreciated.
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Haohui
> >>>>
> >>>> _______________________________________________
> >>>> 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
> > 
> > _______________________________________________
> > 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 clattner at apple.com  Wed Jun 24 10:02:13 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 24 Jun 2009 10:02:13 -0700
Subject: [LLVMdev] killing vicmp and vfcmp
In-Reply-To: <4A41DA12.90106@free.fr>
References: <4A41AF32.2040106@mxc.ca> <4A41DA12.90106@free.fr>
Message-ID: <1DC9D28B-7ADE-4036-B542-20E56CB3CE9B@apple.com>


On Jun 24, 2009, at 12:47 AM, Duncan Sands wrote:

> Hi Nick,
>
>> Now that icmp and fcmp have supported returning vectors of i1 for a
>> while,
>
> the code generators don't know how to codegen vectors of i1, so does
> this actually work?

No, but there are no clients of them yet.

-Chris


From juanc.martinez.santos at gmail.com  Wed Jun 24 10:17:54 2009
From: juanc.martinez.santos at gmail.com (Juan Carlos Martinez Santos)
Date: Wed, 24 Jun 2009 13:17:54 -0400
Subject: [LLVMdev] Internal passes in LLVMC
Message-ID: <d17b77a40906241017k3751118ha6acc65e82de21a0@mail.gmail.com>

Hello,

When I run llvm-gcc -emit-llvm hello.c -c -o hello.bc... what are the
(default) passes that the driver is using? Where I can information about it?
I want to examinate what are the sequences of passes that LLVM runs in each
process.

Thanks in advance,

-- 
Juan Carlos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090624/0ee35599/attachment.html>

From clattner at apple.com  Wed Jun 24 10:21:29 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 24 Jun 2009 10:21:29 -0700
Subject: [LLVMdev] proposal to simplify isel/asmprinter interaction
	with	globals
In-Reply-To: <5E343D57-E3E2-4C45-B3B1-952D90AC5ACF@apple.com>
References: <5E343D57-E3E2-4C45-B3B1-952D90AC5ACF@apple.com>
Message-ID: <3B15E918-4C39-40DC-9FF1-D9356BC458A1@apple.com>

Ok, not too much screaming :), I'll see what I can do.

-Chris

On Jun 20, 2009, at 7:30 PM, Chris Lattner wrote:

> Hi All,
>
> I'm working on various cleanups and simplifications to the
> asmprinters.  One thing that is driving me nuts is that the
> asmprinters currently "reverse engineer" a lot of information when
> printing an operand that isel had when it created it.
>
> I'm specifically talking about all the suffixes generated by isel,
> like $non_lazy_ptr, @TLSGD, @NTPOFF, (%rip) etc.  These are all
> "magic" things that the assembler uses (for example, it generates a
> reference to a global's GOT entry instead of to the global itself).
>
> The thing that is really frustrating to me is that the asmprinters
> need to reverse engineer what isel *meant* in order to output the
> right thing.  For example, to determine whether to emit $non_lazy_ptr,
> it uses a logic tree like this:
>
>     if (shouldPrintStub(TM, Subtarget)) {
>       // Link-once, declaration, or Weakly-linked global variables  
> need
>       // non-lazily-resolved stubs
>       if (GV->isDeclaration() || GV->isWeakForLinker()) {
>         // Dynamically-resolved functions need a stub for the  
> function.
>         if (GV->hasHiddenVisibility()) {
>           if (!GV->isDeclaration() && !GV->hasCommonLinkage())
>   ...
>           else {
>             printSuffixedName(Name, "$non_lazy_ptr");
>           }
>         } else {
>           printSuffixedName(Name, "$non_lazy_ptr");
>         }
>
>  where shouldPrintStub is:
>
> static inline bool shouldPrintStub(TargetMachine &TM, const
> X86Subtarget* ST) {
>   return ST->isPICStyleStub() && TM.getRelocationModel() !=
> Reloc::Static;
> }
>
> This is really redundant with isel, because isel also needs to know
> exactly which GV references go through a stub so that it isels the
> access correctly.
>
> My proposed fix for this is to add an 'unsigned char' slot to
> MachineOperand that holds a target-specific enum value.  The code in
> asmprinter would be reduced to:
>
> switch (theoperandenum) {
> case X86::MO_Flag_non_lazy_ptr:
>   O << "$non_lazy_ptr";
>   break;
> case X86::MO_Flag_TLSGD:
>   O << "@TLSGD";
>   break;
> case X86::MO_Flag_NTPOFF:
>   O << "@NTPOFF";
>   break;
>
>
> etc.  The possible set of suffixes and modifiers are all target-
> specific, so the main code generator would just pass them through (as
> it does now).
>
> Does anyone have any objections to this?
>
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



From jon at ffconsultancy.com  Wed Jun 24 12:10:39 2009
From: jon at ffconsultancy.com (Jon Harrop)
Date: Wed, 24 Jun 2009 20:10:39 +0100
Subject: [LLVMdev] Garbage collection implementation
In-Reply-To: <4A41CF34.5020809@brouhaha.com>
References: <4A41CF34.5020809@brouhaha.com>
Message-ID: <200906242010.39227.jon@ffconsultancy.com>

On Wednesday 24 June 2009 08:01:08 Eric Smith wrote:
> Jon Harrop wrote:
>  > The simplest way is surely to reuse HLVM because it provides
>
> everything you
>
>  > need and is even written in the right language! ;-)
>
> Is there a web page with HLVM docs?  There's a README.txt in the
> subversion repository:
>
>     https://llvm.org/svn/llvm-project/hlvm/trunk/README.txt
>
> which says:
>
>     HLVM comes with documentation in HTML format. These are provided in
> the docs
>     directory. Please visit http://llvm.org/docs/hlvm/ to get an index
> of the
>     documentation that is available.
>
> but unfortunately that URL yields a 404.
>
> While I could check the docs out of subversion myself (assuming they're
> actually there, which I haven't verified), putting the docs online for
> easy access would be much more conducive to attracting users and or
> developers to HLVM.

Hi Eric,

As Marc explained, my HLVM project is a new HLVM project and you have found an 
older HLVM project by (IIRC) Reid Spencer.

I agree that the docs should be on-line somewhere and my docs are not. I'll 
get them up on our company site ASAP and advertise them here.

Many thanks,
-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e


From gordonhenriksen at me.com  Wed Jun 24 11:04:15 2009
From: gordonhenriksen at me.com (Gordon Henriksen)
Date: Wed, 24 Jun 2009 14:04:15 -0400
Subject: [LLVMdev] Garbage collection implementation
In-Reply-To: <20090623132922.GA31918@softlab.ece.ntua.gr>
References: <20090623132922.GA31918@softlab.ece.ntua.gr>
Message-ID: <0FA55789-1387-4D26-A09C-1A3F5E131503@me.com>

Hi Angelos,

I think in theory you should be able to use LLVM's shadow stack  
support with your runtime, but you'll need to save and restore the  
shadow stack's head pointer along with the stack register. Did you  
find that using the shadow stack inhibits TCO? If so, that might be  
fixable.

— Gordon

On 2009-06-23, at 09:29, Angelos Manousaridis wrote:

> I am using LLVM as the last stage of a compiler in order to easily  
> produce a
> binary in native code. My compiler is implemented in Ocaml and has  
> various
> layers of languages. In the last layer prior to LLVM, I have a value  
> which has
> been converted to CPS, closure and hoisting (of functions).
>
> I am now trying to write a garbage collector for this language. The  
> shadow
> stack is not suitable for me, because essentially there is no stack  
> in my case!
> All the function calls are tail calls and without tail recursive  
> optimization
> and stack re-use, the binary is useless.
>
> My goal for now is to write a simple stop-the-world, semispace  
> collector. To
> cut a long story sort, I need to implement an allocation function  
> like this:
>
> if ( there is enough space ) {
>  allocate space;
> } else {
>  dump all live physical registers on the stack;
>  garbage collect;
>  restore from stack, using the new locations;
> }
>
> The tricky part is the "dump all live registers". I spent quite some  
> time
> reading the documentation and have come up to two alternatives. Either
> implement a new pass which reads the live variable analysis and  
> spills all
> registers to the stack at this point, or implement a new intrinsic  
> which spills
> all registers to the stack (after gc, I have to reload registers  
> manually).
>
> Neither of these ideas appears easy, and I am wondering if there is  
> a simpler
> way around this. To my understanding, there is neither a register  
> map or any
> sort of runtime-contract regarding the registers. Also, I need to  
> work my way
> among the LLVM optimizations which move values around registers (for  
> instance
> the fastcc convention which is essential for tail recursive  
> optimization).




From gordonhenriksen at me.com  Wed Jun 24 11:06:07 2009
From: gordonhenriksen at me.com (Gordon Henriksen)
Date: Wed, 24 Jun 2009 14:06:07 -0400
Subject: [LLVMdev] Adding safe-point code generation
In-Reply-To: <bb55930e0906231218x719327fav745c12871dbd6290@mail.gmail.com>
References: <bb55930e0906212249k6dd406b4x514867cc2d02086c@mail.gmail.com>
	<88B97DD9-F834-4629-9A67-FE5D429A7EE5@me.com>
	<bb55930e0906231218x719327fav745c12871dbd6290@mail.gmail.com>
Message-ID: <DD0674B0-7412-4273-88C6-17F0C8B84F5F@me.com>


On 2009-06-23, at 15:18, Jeffrey Yasskin wrote:

> On Tue, Jun 23, 2009 at 4:18 AM, Gordon Henriksen <gordonhenriksen at me.com 
> > wrote:
> Hi Jeffrey,
>
> On 2009-06-22, at 01:49, Jeffrey Yasskin wrote:
>
>> I need to add thread-switching support to Unladen Swallow's JIT,  
>> and LLVM's safe point support looks like a good way to get code  
>> into all the right places. However, http://llvm.org/docs/GarbageCollection.html#collector-algos 
>>  points out that there's no way to emit code at safe points yet,  
>> and there are no loop safe points at all. So I'll be trying to  
>> implement them.
>>
>> Is there anything I should know before starting?
>
> Sounds like you've got the right idea.
>
>> One way to do this might be to add a FunctionPass to  
>> LLVMTargetMachine::addCommonCodeGenPasses() alongside  
>> createGCLoweringPass(), which would insert user-defined code for  
>> safe points. Unfortunately, code inserted there would stick around  
>> in the IR after the machine code was emitted, and if the function  
>> were JITted again, we'd get duplicate safe points.
>
> Unfortunately, I don't believe this is workable. It would make this  
> work much easier if it were.
>
>> Another way to do it might be to add a MachineFunction pass next to  
>> createGCMachineCodeAnalysisPass() (or instead of it), which could  
>> emit appropriate MachineInstructions to implement the safe point.  
>> This, of course, forces safe points to be written in  
>> MachineInstructions instead of IR instructions, which isn't ideal.
>
> I think this is the way to go, though it's also the most involved.  
> My primary rationale is that code generation can hack on the CFG,  
> even introducing loops where there were none expressed in the IR. It  
> could be that I'm being unnecessarily pessimistic on this point,  
> though.
>
> As a specific example of the code generator hacking on the CFG, take  
> atomic operations which expand to loops on architectures which use  
> load-reserved/store-conditional to implement these primitives. It  
> may not be necessary or desirable to add safe points to these loops,  
> but perhaps should be preferred on the basis o correctness.
>
> As another example, consider a 64-bit integer divide on a 32-bit  
> architecture expanding to a libcall. Some, but perhaps not all,  
> collection algorithms would want to emit safe point code for this  
> call, but it simply does not exist in the IR to instrument.
>
> I'm worried that it'll be necessary for some garbage collectors and  
> hurt performance too much for others. Should it be configurable? I  
> don't need to insert safe points in such loops and calls for my use,  
> so I'd try to make it extensible, but then leave support for these  
> loops and calls to someone who actually needs them.

That sounds best.

> Also, code injection of the form 'give me 8 bytes of noops at each  
> safe point' and 'insert a cold instruction sequence at the end of  
> the function' are best expressed at the machine code level. Safe  
> points are hot code and unusual, target-specific techniques are  
> regularly used with them if you survey the literature, so a design  
> which accommodates that reality is preferred, even though hacking on  
> the MachineFunction representation is less pleasant than the IR.
>
> I'd like to allow target-specific techniques, but also allow target- 
> independent techniques, and the target-independent techniques are  
> more important for what I'm actually doing. Now that I've looked  
> into MachineInstructions more, it looks like it's impossible to use  
> them in a target-independent way.

I agree. I think the lowering would actually occur in the  
SelectionDAG, rather than at the MachineFunction level.

> One element of this design that is desirable from a design  
> perspective is that it preserves the original IR. Chris has said  
> that it's a long-term goal of LLVM to not mangle the Function during  
> code generation, and this moves in that direction instead of  
> regressing.
>
> I definitely like that feature.

Yep.

>> Another way might be to run a pass over the IR inserting  
>> llvm.safepoint() calls, which could be implemented as a function in  
>> the module. Then we'd want a MachineFunction pass to inline this  
>> for us during codegen. The llvm.safepoint() calls could be easily  
>> identified and removed if the IR needs to be re-used.
>
> I see this as fairly equivalent to the first option.
>
> I don't, because the user can control how they lower  
> llvm.safepoint(). For uses like mine, where I'd rather write the  
> safe point in IR, I can implement it as a function (if I have a  
> selectiondag-level inliner). For more advanced garbage collectors,  
> they can implement it as a custom lowering in their target. The  
> biggest downside of an llvm.safepoint intrinsic would be that it  
> couldn't capture loops and calls introduced by lowering, unless  
> those lowerings explicitly introduced new safepoints.

Right.

> Also, regardless, stop point markers (a label is actually generated)  
> need to survive as such into the MachineFunction representation else  
> we'll never be able to generate a register map.
>
> Hope that helps,
> Gordon
>
>
> P.S. There's an interesting circularity which I may not have  
> accounted for in the original design: If code is injected at each  
> safe point, and a call instruction is injected, do we need to  
> generate another safe point for that call? Clearly, the expansion of  
> a safe point cannot be recursive with itself; but I think that we  
> should allow generating a register map at the return address of that  
> call, just as some collectors may want to instrument the libcall  
> case discussed above.
>
> Actually, this distinction between safe points for inserting code  
> and safe points for frame maps is probably is a critical design  
> issue for your use case. Our current definition of a safe point is  
> at the return address of a call instruction, which is precisely  
> what's required to walk the stack. This is NOT the location where  
> you want to add a call to your runtime.
>
> I think you're saying that we need two kinds of safe points: points  
> at which to insert code, and points that the  
> GCFunctionInfo::iterator traverses. The code-inserting safe points  
> could insert traversed safe points.

That's a good summary of the problem, yes.

— Gordon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090624/f5383227/attachment.html>

From mjr at cs.wisc.edu  Wed Jun 24 11:06:08 2009
From: mjr at cs.wisc.edu (Matt Renzelmann)
Date: Wed, 24 Jun 2009 13:06:08 -0500
Subject: [LLVMdev] How to add a trivial LLVM intrinsic
In-Reply-To: <4A41D570.5000009@free.fr>
References: <005301c9f447$7ddc1340$799439c0$@wisc.edu>
	<4A41D570.5000009@free.fr>
Message-ID: <001401c9f4f6$764c16c0$62e44440$@wisc.edu>

Thank you for your reply--I've now done that.  Unfortunately, there's a new
error now:

------------
Cannot yet select: intrinsic %llvm.test_intrinsic
test.c:25: internal compiler error: Aborted
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://developer.apple.com/bugreporter> for instructions.
------------

I've switched to using LLVM-2.5 instead of the latest SVN version, but I
made all the same changes described in the previous email.  After making the
changes, I built LLVM, and then built the GCC front end.

I traced the "Cannot yet select" print statement to DAGISelEmitter.cpp, but
am unsure how to proceed.

Thanks again for your help,
Matt

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Duncan Sands
Sent: Wednesday, June 24, 2009 2:28 AM
To: LLVM Developers Mailing List
Subject: Re: [LLVMdev] How to add a trivial LLVM intrinsic

Hi,

> After invoking:
> llvm-gcc -g test.c -o test.native
> -----------------
> The compiler returns:
> cc1: Function.cpp:323: unsigned int llvm::Function::getIntrinsicID(bool)
> const: Assertion `noAssert && "Invalid LLVM intrinsic name"' failed.
> test.c:24: internal compiler error: Aborted

did you rebuild llvm-gcc after building llvm with your new intrinsic
defined?

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 samuraileumas at yahoo.com  Wed Jun 24 11:16:19 2009
From: samuraileumas at yahoo.com (Samuel Crow)
Date: Wed, 24 Jun 2009 11:16:19 -0700 (PDT)
Subject: [LLVMdev] searching mailing list (was Re:Replacing instruction in
	LLVM IR by an intrinsics)
In-Reply-To: <op.uv1b4f2c0lgsd9@localhost.localdomain>
References: <op.uv1b4f2c0lgsd9@localhost.localdomain>
Message-ID: <992262.65168.qm@web62005.mail.re1.yahoo.com>





> 
> btw.: Is there a way how to search archived messages from this mailing list? 
> Google with site:lists.cs.uiuc.edu
> does not work very much.

Try http://www.nabble.com/LLVM---Dev-f692.html

--Sam



      


From jyasskin at google.com  Wed Jun 24 12:02:40 2009
From: jyasskin at google.com (Jeffrey Yasskin)
Date: Wed, 24 Jun 2009 12:02:40 -0700
Subject: [LLVMdev] JITEventListener for eventual profiling and maybe gdb
	support
Message-ID: <bb55930e0906241202s1e55634did93db40593beba28@mail.gmail.com>

I intend to use this to support oprofile's ability to symbolize JITted
code through the interface described at
http://oprofile.sourceforge.net/doc/devel/jit-interface.html. I
believe the interface will also be useful for gdb support. I'm
considering adding some flags to the JITEventListener to let the JIT
avoid collecting information no listener is going to use, but I won't
do that until there's a need.

I've added EmittedFunctionDetails in this patch so that I don't have
to change the NotifyFunctionEmitted() interface in a future patch. To
record line number information, oprofile wants an array of structs of
the form:

 struct debug_line_info {
       unsigned long vma;
       unsigned int lineno;
       /* The filename format is unspecified, absolute path, relative etc. */
       char const * filename;
 };

so I'll add enough information to produce that to the
EmittedFunctionDetails in a later patch.

Chris mentioned that someone may want to extend this to fire events on
stub emission too.

Let me know what you think.
Jeffrey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: event-listener.patch
Type: application/octet-stream
Size: 34354 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090624/3563eefe/attachment.obj>

From baldrick at free.fr  Wed Jun 24 12:37:49 2009
From: baldrick at free.fr (Duncan Sands)
Date: Wed, 24 Jun 2009 21:37:49 +0200
Subject: [LLVMdev] How to add a trivial LLVM intrinsic
In-Reply-To: <001401c9f4f6$764c16c0$62e44440$@wisc.edu>
References: <005301c9f447$7ddc1340$799439c0$@wisc.edu>	<4A41D570.5000009@free.fr>
	<001401c9f4f6$764c16c0$62e44440$@wisc.edu>
Message-ID: <4A42808D.2010206@free.fr>

Hi Matt,

> Thank you for your reply--I've now done that.  Unfortunately, there's a new
> error now:
> 
> ------------
> Cannot yet select: intrinsic %llvm.test_intrinsic
> test.c:25: internal compiler error: Aborted

that's because you didn't tell the code generators what
they should do with your intrinsic.

Ciao,

Duncan.


From criswell at cs.uiuc.edu  Wed Jun 24 12:44:42 2009
From: criswell at cs.uiuc.edu (John Criswell)
Date: Wed, 24 Jun 2009 14:44:42 -0500
Subject: [LLVMdev] Garbage collection implementation
In-Reply-To: <20090623132922.GA31918@softlab.ece.ntua.gr>
References: <20090623132922.GA31918@softlab.ece.ntua.gr>
Message-ID: <4A42822A.7050005@cs.uiuc.edu>

Angelos Manousaridis wrote:
> I am using LLVM as the last stage of a compiler in order to easily produce a
> binary in native code. My compiler is implemented in Ocaml and has various
> layers of languages. In the last layer prior to LLVM, I have a value which has
> been converted to CPS, closure and hoisting (of functions).
>
> I am now trying to write a garbage collector for this language. The shadow
> stack is not suitable for me, because essentially there is no stack in my case!
> All the function calls are tail calls and without tail recursive optimization
> and stack re-use, the binary is useless.
>
> My goal for now is to write a simple stop-the-world, semispace collector. To
> cut a long story sort, I need to implement an allocation function like this:
>
> if ( there is enough space ) {
>   allocate space;
> } else {
>   dump all live physical registers on the stack;
>   garbage collect;
>   restore from stack, using the new locations;
> }
>
> The tricky part is the "dump all live registers". I spent quite some time
> reading the documentation and have come up to two alternatives. Either
> implement a new pass which reads the live variable analysis and spills all
> registers to the stack at this point, or implement a new intrinsic which spills
> all registers to the stack (after gc, I have to reload registers manually).
>   
The latter should be relatively easy to implement provided that you are
comfortable with the assembly language for your target architecture.
LLVM IR supports inline assembly. You can write an LLVM transform that
inserts one inline assembly instruction that saves all the general
purpose registers and another that restores all the general purpose
registers.

In this way, you don't have to write a code generator pass (which might
offer better optimization but may be more work).

If you need example code for register save/restore on i386, please let
me know. I wrote some code for the context switching instructions for
the Secure Virtual Architecture (SVA) project which must save and
restore registers; I can ask my advisor if we can provide those to you.

-- John T.

> Neither of these ideas appears easy, and I am wondering if there is a simpler
> way around this. To my understanding, there is neither a register map or any
> sort of runtime-contract regarding the registers. Also, I need to work my way
> among the LLVM optimizations which move values around registers (for instance
> the fastcc convention which is essential for tail recursive optimization).
>
> --
> Angelos Manousaridis
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   



From mjr at cs.wisc.edu  Wed Jun 24 12:46:42 2009
From: mjr at cs.wisc.edu (Matt Renzelmann)
Date: Wed, 24 Jun 2009 14:46:42 -0500
Subject: [LLVMdev] How to add a trivial LLVM intrinsic
In-Reply-To: <4A42808D.2010206@free.fr>
References: <005301c9f447$7ddc1340$799439c0$@wisc.edu>	<4A41D570.5000009@free.fr>	<001401c9f4f6$764c16c0$62e44440$@wisc.edu>
	<4A42808D.2010206@free.fr>
Message-ID: <002401c9f504$82a70cf0$87f526d0$@wisc.edu>

Thank you again for your help.  Assuming my experimental "noop" intrinsic is
intended to be target independent, what file should I modify to provide the
code generator with the necessary information?  I've already modified:

./lib/CodeGen/IntrinsicLowering.cpp
./lib/Target/CBackend/CBackend.cpp
./include/llvm/Intrinsics.td

Presumably it's not one of those?  Or, if it is, I imagine I've simply
screwed something up?

Thanks again,
Matt

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Duncan Sands
Sent: Wednesday, June 24, 2009 2:38 PM
To: LLVM Developers Mailing List
Subject: Re: [LLVMdev] How to add a trivial LLVM intrinsic

Hi Matt,

> Thank you for your reply--I've now done that.  Unfortunately, there's a
new
> error now:
> 
> ------------
> Cannot yet select: intrinsic %llvm.test_intrinsic
> test.c:25: internal compiler error: Aborted

that's because you didn't tell the code generators what
they should do with your intrinsic.

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 jyasskin at google.com  Wed Jun 24 13:26:12 2009
From: jyasskin at google.com (Jeffrey Yasskin)
Date: Wed, 24 Jun 2009 13:26:12 -0700
Subject: [LLVMdev] JITEventListener for eventual profiling and maybe gdb
	support
In-Reply-To: <bb55930e0906241202s1e55634did93db40593beba28@mail.gmail.com>
References: <bb55930e0906241202s1e55634did93db40593beba28@mail.gmail.com>
Message-ID: <bb55930e0906241326l76299679hd7ee7b600d45bff5@mail.gmail.com>

Ack, sorry. I should have sent this to llvm-commits instead. :-P
Followups there please.

On Wed, Jun 24, 2009 at 12:02 PM, Jeffrey Yasskin<jyasskin at google.com> wrote:
> I intend to use this to support oprofile's ability to symbolize JITted
> code through the interface described at
> http://oprofile.sourceforge.net/doc/devel/jit-interface.html. I
> believe the interface will also be useful for gdb support. I'm
> considering adding some flags to the JITEventListener to let the JIT
> avoid collecting information no listener is going to use, but I won't
> do that until there's a need.
>
> I've added EmittedFunctionDetails in this patch so that I don't have
> to change the NotifyFunctionEmitted() interface in a future patch. To
> record line number information, oprofile wants an array of structs of
> the form:
>
>  struct debug_line_info {
>       unsigned long vma;
>       unsigned int lineno;
>       /* The filename format is unspecified, absolute path, relative etc. */
>       char const * filename;
>  };
>
> so I'll add enough information to produce that to the
> EmittedFunctionDetails in a later patch.
>
> Chris mentioned that someone may want to extend this to fire events on
> stub emission too.
>
> Let me know what you think.
> Jeffrey
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: event-listener.patch
Type: application/octet-stream
Size: 34354 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090624/49203279/attachment.obj>

From robert at muth.org  Wed Jun 24 14:20:57 2009
From: robert at muth.org (robert muth)
Date: Wed, 24 Jun 2009 17:20:57 -0400
Subject: [LLVMdev] patch for llc/ARM: added mechanism to move switch
	tables from .text -> .data; also cleanup and documentation
In-Reply-To: <A81A63F1-DB89-45FD-A5DB-32E09A8C69EB@apple.com>
References: <8e3491100906021826p4530f341xbb168d260c21342e@mail.gmail.com>
	<0453D1AB-FA5D-4947-BE50-02223AB8955B@apple.com>
	<8e3491100906070659k481580afk2d562a6c4a21a2a4@mail.gmail.com>
	<C2EC9000-8447-42CB-B3CD-5DB1652C356F@apple.com>
	<8e3491100906081442l3417b3e9nf3abeda39f8f2514@mail.gmail.com>
	<A81A63F1-DB89-45FD-A5DB-32E09A8C69EB@apple.com>
Message-ID: <8e3491100906241420h5facc3av280ae95d802f932c@mail.gmail.com>

Evan:

Sorry for the late follow up, I was out of town last week.
Enclosed please find the updated patch including all
your suggestions and a dejagnus test.

Robert

On Thu, Jun 11, 2009 at 2:27 PM, Evan Cheng <evan.cheng at apple.com> wrote:

>
> On Jun 8, 2009, at 2:42 PM, robert muth wrote:
>
> > On Sun, Jun 7, 2009 at 11:53 PM, Evan Cheng <evan.cheng at apple.com>
> > wrote:
> >>
> >> On Jun 7, 2009, at 6:59 AM, robert muth wrote:
> >>
> >>> On Sat, Jun 6, 2009 at 4:51 PM, Evan Cheng<evan.cheng at apple.com>
> >>> wrote:
> >>>> +cl::opt<std::string> FlagJumpTableSection("jumptable-section",
> >>>> +
> >>>> cl::init(".data.jtab"));
> >>>> +
> >>>
> >>> I thought it would be nice to group all the jumptables together.
> >>> But as long as it stays configurable, I am fine to change the
> >>> default
> >>> to ".data".
> >>
> >> There is already a TargetAsmInfo::JumpTableDataSection. Why not just
> >> use that?
> >
> > Nice find. I will use that and possible change the current setting,
> > ".const", if it does not work,
> >
> >>>
> >>>> Is this necessary? Why not just put it in the normal data section?
> >>>> Also "outline" jumptable seems like a strange term. Can you think
> >>>> of
> >>>> something else?
> >>>
> >>>
> >>> Yes, that is a tough one. How about "NonInline" instead.
> >>
> >> Or "OutOfLine"?
> >
> > That works for me.
> >
> >> Please add a test case as well. Thanks,
> >
> > I am not sure how to go about testing.
>
> For this please just add a test case to the llvm dejagnu tests.
>
> thanks,
>
> Evan
>
> >
> > I have  a script that compiles a bunch of test
> > programs (gnu c torture test, etc.) and then runs the executables
> > on qemu.  I run this script with and without my flags and
> > make sure that I do not introduce any new problems
> > -- there are currently plenty of vararg issues.
> >
> > I was thinking of sending this script to the list
> > or maybe checking it into the llvm tree.
> >
> > The key is that whatever tests there are they should just
> > be run with and without the new flag.
> > How do you run backend tests?
> >
> > Robert
> >
> >
> >
> >
> >> Evan
> >>
> >>>
> >>> Robert
> >>>
> >>>> Thanks,
> >>>> Evan
> >>>>
> >>>> Sent from my iPhone
> >>>> On Jun 2, 2009, at 6:26 PM, robert muth <robert at muth.org> wrote:
> >>>>
> >>>> Hi:
> >>>>
> >>>> This is my first patch submission. Hopefully, this is the proper
> >>>> the
> >>>> protocol.
> >>>> Attached is a patch for the llc ARM backend:
> >>>>
> >>>> Added mechanism to generate switch table in a data section
> >>>> rather than having it interleaved with the code.
> >>>> This is controlled by command line flags and off by default.
> >>>> Also, tried to document and improve the code where I modified it.
> >>>>
> >>>> Robert
> >>>>
> >>>> <llc.patch.txt>
> >>>>
> >>>> _______________________________________________
> >>>> 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
> >>>>
> >>>>
> >>>
> >>> _______________________________________________
> >>> 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
> >>
> >
> > _______________________________________________
> > 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.llvm.org/pipermail/llvm-dev/attachments/20090624/01802d9c/attachment.html>
-------------- next part --------------
Index: test/CodeGen/ARM/switch.ll
===================================================================
--- test/CodeGen/ARM/switch.ll	(revision 0)
+++ test/CodeGen/ARM/switch.ll	(revision 0)
@@ -0,0 +1,82 @@
+; Note: jump table has 7 entries
+; RUN: llvm-as < %s | llc -march=arm  | \
+; RUN:   grep .long | count 7
+; Note: no section change
+; RUN: llvm-as < %s | llc -march=arm  | \
+; RUN:   grep .text | count 1
+; Note: no data section
+; RUN: llvm-as < %s | llc -march=arm  | \
+; RUN:   not grep .data
+;
+; Note: jump table has 7 entries + 1 entry for the table start
+; RUN: llvm-as < %s | llc -march=arm  -outline-jumptables | \
+; RUN:   grep .long | count 8
+; Note one section change
+; RUN: llvm-as < %s | llc -march=arm  -outline-jumptables | \
+; RUN:   grep .text | count 2
+; Note: has data section
+; RUN: llvm-as < %s | llc -march=arm  -outline-jumptables | \
+; RUN:   grep .data | count 1
+
+
+define i32 @f(i32 %i) nounwind {
+entry:
+	%i_addr = alloca i32		; <i32*> [#uses=2]
+	%retval = alloca i32		; <i32*> [#uses=2]
+	%0 = alloca i32		; <i32*> [#uses=8]
+	%"alloca point" = bitcast i32 0 to i32		; <i32> [#uses=0]
+	store i32 %i, i32* %i_addr
+	%1 = load i32* %i_addr, align 4		; <i32> [#uses=1]
+	switch i32 %1, label %bb7 [
+		i32 -2, label %bb
+		i32 -1, label %bb1
+		i32 0, label %bb2
+		i32 1, label %bb3
+		i32 2, label %bb4
+		i32 3, label %bb5
+		i32 4, label %bb6
+	]
+
+bb:		; preds = %entry
+	store i32 33, i32* %0, align 4
+	br label %bb8
+
+bb1:		; preds = %entry
+	store i32 0, i32* %0, align 4
+	br label %bb8
+
+bb2:		; preds = %entry
+	store i32 7, i32* %0, align 4
+	br label %bb8
+
+bb3:		; preds = %entry
+	store i32 4, i32* %0, align 4
+	br label %bb8
+
+bb4:		; preds = %entry
+	store i32 3, i32* %0, align 4
+	br label %bb8
+
+bb5:		; preds = %entry
+	store i32 15, i32* %0, align 4
+	br label %bb8
+
+bb6:		; preds = %entry
+	store i32 9, i32* %0, align 4
+	br label %bb8
+
+bb7:		; preds = %entry
+	store i32 999, i32* %0, align 4
+	br label %bb8
+
+bb8:		; preds = %bb6, %bb5, %bb4, %bb3, %bb2, %bb1, %bb
+	%2 = load i32* %0, align 4		; <i32> [#uses=1]
+	store i32 %2, i32* %retval, align 4
+	br label %return
+
+return:		; preds = %bb8
+	%retval9 = load i32* %retval		; <i32> [#uses=1]
+	ret i32 %retval9
+}
+
+
Index: lib/Target/ARM/ARMISelLowering.h
===================================================================
--- lib/Target/ARM/ARMISelLowering.h	(revision 74072)
+++ lib/Target/ARM/ARMISelLowering.h	(working copy)
@@ -202,9 +202,10 @@
     /// make the right decision when generating code for different targets.
     const ARMSubtarget *Subtarget;
 
-    /// ARMPCLabelIndex - Keep track the number of ARM PC labels created.
-    ///
+    /// ARMPCLabelIndex - Keep track of the number of ARM PC labels created.
     unsigned ARMPCLabelIndex;
+    /// ARMJumpTableIndex - Keep track of the number ofJump Tables
+    unsigned ARMJumpTableIndex;
 
     void addTypeForNEON(MVT VT, MVT PromotedLdStVT, MVT PromotedBitwiseVT);
     void addDRTypeForNEON(MVT VT);
Index: lib/Target/ARM/ARMConstantPoolValue.h
===================================================================
--- lib/Target/ARM/ARMConstantPoolValue.h	(revision 74072)
+++ lib/Target/ARM/ARMConstantPoolValue.h	(working copy)
@@ -25,6 +25,7 @@
   enum ARMCPKind {
     CPValue,
     CPNonLazyPtr,
+    CPDataSegmentJumpTable,
     CPStub
   };
 }
@@ -54,7 +55,6 @@
   ARMConstantPoolValue(GlobalValue *GV, ARMCP::ARMCPKind Kind,
                        const char *Modifier);
 
-
   GlobalValue *getGV() const { return GV; }
   const char *getSymbol() const { return S; }
   const char *getModifier() const { return Modifier; }
@@ -63,6 +63,9 @@
   unsigned getLabelId() const { return LabelId; }
   bool isNonLazyPointer() const { return Kind == ARMCP::CPNonLazyPtr; }
   bool isStub() const { return Kind == ARMCP::CPStub; }
+  bool isValue() const { return Kind == ARMCP::CPValue; }
+  bool isDataSegmentJumpTable() const {
+    return Kind == ARMCP::CPDataSegmentJumpTable; }
   unsigned char getPCAdjustment() const { return PCAdjust; }
 
   virtual int getExistingMachineCPValue(MachineConstantPool *CP,
Index: lib/Target/ARM/AsmPrinter/ARMAsmPrinter.cpp
===================================================================
--- lib/Target/ARM/AsmPrinter/ARMAsmPrinter.cpp	(revision 74072)
+++ lib/Target/ARM/AsmPrinter/ARMAsmPrinter.cpp	(working copy)
@@ -33,13 +33,17 @@
 #include "llvm/ADT/Statistic.h"
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringSet.h"
+#include "llvm/Support/CommandLine.h"
 #include "llvm/Support/Compiler.h"
 #include "llvm/Support/Mangler.h"
 #include "llvm/Support/MathExtras.h"
 #include "llvm/Support/raw_ostream.h"
 #include <cctype>
+#include <sstream>
 using namespace llvm;
 
+extern cl::opt<bool> FlagOutlineJumpTables;
+
 STATISTIC(EmittedInsts, "Number of machine instrs printed");
 
 namespace {
@@ -141,6 +145,7 @@
     /// EmitMachineConstantPoolValue - Print a machine constantpool value to
     /// the .s file.
     virtual void EmitMachineConstantPoolValue(MachineConstantPoolValue *MCPV) {
+      // NOTE: A lot of this code is replicated in  ARMConstantPoolValue::print
       printDataDirective(MCPV->getType());
 
       ARMConstantPoolValue *ACPV = static_cast<ARMConstantPoolValue*>(MCPV);
@@ -157,8 +162,13 @@
       } else if (ACPV->isStub()) {
         FnStubs.insert(Name);
         printSuffixedName(Name, "$stub");
-      } else
+      } else if (ACPV->isDataSegmentJumpTable()) {
+        // requires synchronization with code (grep for "$jumptable$")
+        O << Name << "$jumptable$" << ACPV->getLabelId();
+      } else {
+        assert(ACPV->isValue() && "unknown CP kind");
         O << Name;
+      }
       if (ACPV->hasModifier()) O << "(" << ACPV->getModifier() << ")";
       if (ACPV->getPCAdjustment() != 0) {
         O << "-(" << TAI->getPrivateGlobalPrefix() << "PC"
@@ -757,12 +767,31 @@
   }
 }
 
+
 void ARMAsmPrinter::printJTBlockOperand(const MachineInstr *MI, int OpNo) {
-  const MachineOperand &MO1 = MI->getOperand(OpNo);
-  const MachineOperand &MO2 = MI->getOperand(OpNo+1); // Unique Id
-  unsigned JTI = MO1.getIndex();
-  O << TAI->getPrivateGlobalPrefix() << "JTI" << getFunctionNumber()
-    << '_' << JTI << '_' << MO2.getImm() << ":\n";
+  std::stringstream  prefix;
+
+  const unsigned JTI =  MI->getOperand(OpNo).getIndex();
+  const unsigned uid = MI->getOperand(OpNo+1).getImm();
+
+  if (FlagOutlineJumpTables) {
+    // needs to be synchronized with ARMConstantPoolValue.cpp
+    prefix << ".T$jumptable$" << uid;
+  } else {
+    // needs to be synchronized with other places in this file
+    prefix  << TAI->getPrivateGlobalPrefix() << "JTI" << getFunctionNumber()
+            << '_' << JTI << '_' << uid;
+  }
+
+  if (FlagOutlineJumpTables) {
+    // switch out of text section
+    O << TAI->getJumpTableDataSection();
+    O << ".align 4\n";
+    O << "\n\n";
+  }
+
+  // the table label
+  O << prefix.str() << ":\n";
 
   const char *JTEntryDirective = TAI->getJumpTableDirective();
   if (!JTEntryDirective)
@@ -777,24 +806,28 @@
   for (unsigned i = 0, e = JTBBs.size(); i != e; ++i) {
     MachineBasicBlock *MBB = JTBBs[i];
     if (UseSet && JTSets.insert(MBB).second)
-      printPICJumpTableSetLabel(JTI, MO2.getImm(), MBB);
+      printPICJumpTableSetLabel(JTI, uid, MBB);
 
     O << JTEntryDirective << ' ';
     if (UseSet)
-      O << TAI->getPrivateGlobalPrefix() << getFunctionNumber()
-        << '_' << JTI << '_' << MO2.getImm()
-        << "_set_" << MBB->getNumber();
+      O << prefix.str() << "_set_" << MBB->getNumber();
     else if (TM.getRelocationModel() == Reloc::PIC_) {
       printBasicBlockLabel(MBB, false, false, false);
       // If the arch uses custom Jump Table directives, don't calc relative to JT
       if (!TAI->getJumpTableDirective()) 
-        O << '-' << TAI->getPrivateGlobalPrefix() << "JTI"
-          << getFunctionNumber() << '_' << JTI << '_' << MO2.getImm();
+        O << '-' << prefix.str();
     } else
       printBasicBlockLabel(MBB, false, false, false);
     if (i != e-1)
       O << '\n';
   }
+
+  if (FlagOutlineJumpTables) {
+    // switch back into the text section
+    O << "\n\n";
+    O << ".text\n";
+    O << "\n\n";
+  }
 }
 
 
Index: lib/Target/ARM/ARMTargetAsmInfo.cpp
===================================================================
--- lib/Target/ARM/ARMTargetAsmInfo.cpp	(revision 74072)
+++ lib/Target/ARM/ARMTargetAsmInfo.cpp	(working copy)
@@ -52,6 +52,7 @@
   SetDirective = "\t.set\t";
   ProtectedDirective = NULL;
   HasDotTypeDotSizeDirective = false;
+  JumpTableDataSection = "\t.section .data,\"aMS\",%progbits,1\n";
   SupportsDebugInformation = true;
 }
 
@@ -86,6 +87,7 @@
     StaticCtorsSection = "\t.section .ctors,\"aw\",%progbits";
     StaticDtorsSection = "\t.section .dtors,\"aw\",%progbits";
   }
+  JumpTableDataSection = "\t.section .data,\"aMS\",%progbits,1\n";
   SupportsDebugInformation = true;
 }
 
Index: lib/Target/ARM/ARMISelLowering.cpp
===================================================================
--- lib/Target/ARM/ARMISelLowering.cpp	(revision 74072)
+++ lib/Target/ARM/ARMISelLowering.cpp	(working copy)
@@ -36,9 +36,16 @@
 #include "llvm/CodeGen/SelectionDAG.h"
 #include "llvm/Target/TargetOptions.h"
 #include "llvm/ADT/VectorExtras.h"
+#include "llvm/Support/CommandLine.h"
 #include "llvm/Support/MathExtras.h"
+
 using namespace llvm;
 
+
+
+cl::opt<bool> FlagOutlineJumpTables("outline-jumptables",
+                                    cl::desc("move jumptables from text to data"));
+
 static bool CC_ARM_APCS_Custom_f64(unsigned &ValNo, MVT &ValVT, MVT &LocVT,
                                    CCValAssign::LocInfo &LocInfo,
                                    ISD::ArgFlagsTy &ArgFlags,
@@ -1686,27 +1693,119 @@
   return Res;
 }
 
-SDValue ARMTargetLowering::LowerBR_JT(SDValue Op, SelectionDAG &DAG) {
+
+
+// Similar to LowerBR_JT_Inline except that the jumptable
+// is moved to the data segment.
+// This causes a extra load to access the table but keeps the
+// text segment small and avoids some issues with generating PIC
+// Needs to be activated with a commandline flag.
+static SDValue LowerBR_JT_OutOfLine(SDValue Op,
+                                  SelectionDAG &DAG,
+                                  unsigned Num,
+                                  MVT PTy) {
+
   SDValue Chain = Op.getOperand(0);
-  SDValue Table = Op.getOperand(1);
-  SDValue Index = Op.getOperand(2);
-  DebugLoc dl = Op.getDebugLoc();
 
-  MVT PTy = getPointerTy();
-  JumpTableSDNode *JT = cast<JumpTableSDNode>(Table);
+  const JumpTableSDNode *JT = cast<JumpTableSDNode>(Op.getOperand(1));
+  const SDValue Index = Op.getOperand(2);
+
+
+  const DebugLoc dl = Op.getDebugLoc();
+
+  const SDValue UId =  DAG.getConstant(Num, PTy);
+  const SDValue JTI = DAG.getTargetJumpTable(JT->getIndex(), PTy);
+
+  // create a new global symbol for the jumptable
+  ARMConstantPoolValue *CPV = new ARMConstantPoolValue(".T", Num,
+                                          ARMCP::CPDataSegmentJumpTable);
+  const SDValue CPAddr = DAG.getTargetConstantPool(CPV, PTy, 4);
+
+  // An ARM idiosyncrasy: wrap each constant pool entry before accessing it
+  const SDValue Wrapper = DAG.getNode(ARMISD::Wrapper, dl, MVT::i32, CPAddr);
+
+  // Load Table start from constan pool
+  const SDValue Table = DAG.getLoad(PTy, dl, DAG.getEntryNode(), Wrapper, NULL, 0);
+
+  // table entries are 4 bytes, so multiple index by 4
+  const SDValue ScaledIndex = DAG.getNode(ISD::MUL, dl, PTy, Index, DAG.getConstant(4, PTy));
+
+  // add scaled index to table beginning
+  const SDValue TabEntryAddr = DAG.getNode(ISD::ADD, dl, PTy, ScaledIndex, Table);
+  const SDValue JumpTarget = DAG.getLoad(PTy, dl, Chain, TabEntryAddr, NULL, 0);
+
+  return DAG.getNode(ARMISD::BR_JT, dl, MVT::Other, Chain, JumpTarget, JTI, UId);
+}
+
+
+static SDValue LowerBR_JT_Inline(SDValue Op,
+                                 SelectionDAG &DAG,
+                                 bool isPIC,
+                                 MVT PTy) {
+  //  The Jumptable idiom we are aiming for looks somthing like this:
+  //
+  //          .set PCRELV0, (.LJTI9_0_0-(.LPCRELL0+8))
+  //  .LPCRELL0:
+  //          add r3, pc, #PCRELV0
+  //          ldr pc, [r3, +r0, lsl #2]
+  //  .LJTI9_0_0:
+  //          .long    .LBB9_2
+  //          .long    .LBB9_5
+  //          .long    .LBB9_7
+  //          .long    .LBB9_4
+  //          .long    .LBB9_8
+  //
+  // In pic mode the table entries are relative to table beginning
+  // requiring and extra addition
+  //
+  // The code generation logic for ARMISD::BR_JT will also
+  // emit the table (c.f. ARMAsmPrinter::printJTBlockOperand())
+  // Also check  "def BR_JTm" in ARMInstrInfo.td
+
+  // allocate constant pool entry
   ARMFunctionInfo *AFI = DAG.getMachineFunction().getInfo<ARMFunctionInfo>();
-  SDValue UId =  DAG.getConstant(AFI->createJumpTableUId(), PTy);
-  SDValue JTI = DAG.getTargetJumpTable(JT->getIndex(), PTy);
-  Table = DAG.getNode(ARMISD::WrapperJT, dl, MVT::i32, JTI, UId);
-  Index = DAG.getNode(ISD::MUL, dl, PTy, Index, DAG.getConstant(4, PTy));
-  SDValue Addr = DAG.getNode(ISD::ADD, dl, PTy, Index, Table);
-  bool isPIC = getTargetMachine().getRelocationModel() == Reloc::PIC_;
-  Addr = DAG.getLoad(isPIC ? (MVT)MVT::i32 : PTy, dl,
-                     Chain, Addr, NULL, 0);
-  Chain = Addr.getValue(1);
-  if (isPIC)
-    Addr = DAG.getNode(ISD::ADD, dl, PTy, Addr, Table);
-  return DAG.getNode(ARMISD::BR_JT, dl, MVT::Other, Chain, Addr, JTI, UId);
+
+  SDValue Chain = Op.getOperand(0);
+
+  const JumpTableSDNode *JT = cast<JumpTableSDNode>(Op.getOperand(1));
+  const SDValue Index = Op.getOperand(2);
+  const DebugLoc dl = Op.getDebugLoc();
+
+
+  const SDValue UId =  DAG.getConstant(AFI->createJumpTableUId(), PTy);
+
+  const SDValue JTI = DAG.getTargetJumpTable(JT->getIndex(), PTy);
+
+  // this uses pcrel magic to materialize the table start address
+  const SDValue Table = DAG.getNode(ARMISD::WrapperJT, dl, MVT::i32, JTI, UId);
+
+  // table entries are 4 bytes, so multiple index by 4
+   const SDValue ScaledIndex = DAG.getNode(ISD::MUL, dl, PTy, Index, DAG.getConstant(4, PTy));
+
+  // add scaled index to table beginning
+  const SDValue TabEntryAddr = DAG.getNode(ISD::ADD, dl, PTy, ScaledIndex, Table);
+  SDValue JumpTarget;
+  if (isPIC) {
+     JumpTarget = DAG.getLoad((MVT)MVT::i32, dl, Chain, TabEntryAddr, NULL, 0);
+     Chain = JumpTarget.getValue(1);
+     // the table entry is not the actual target but relative to other stuff
+     // TODO: explain the exact magic here
+     JumpTarget = DAG.getNode(ISD::ADD, dl, PTy, JumpTarget, Table);
+  } else {
+    JumpTarget = DAG.getLoad(PTy, dl, Chain, TabEntryAddr, NULL, 0);
+    Chain = JumpTarget.getValue(1);
+  }
+
+  return DAG.getNode(ARMISD::BR_JT, dl, MVT::Other, Chain, JumpTarget, JTI, UId);
+}
+
+SDValue ARMTargetLowering::LowerBR_JT(SDValue Op, SelectionDAG &DAG) {
+  if (FlagOutlineJumpTables) {
+    return LowerBR_JT_OutOfLine(Op, DAG, ++ARMJumpTableIndex, getPointerTy());
+  } else {
+    const bool isPIC = getTargetMachine().getRelocationModel() == Reloc::PIC_;
+    return LowerBR_JT_Inline(Op, DAG, isPIC, getPointerTy());
+  }
 }
 
 static SDValue LowerFP_TO_INT(SDValue Op, SelectionDAG &DAG) {
Index: lib/Target/ARM/ARMConstantPoolValue.cpp
===================================================================
--- lib/Target/ARM/ARMConstantPoolValue.cpp	(revision 74072)
+++ lib/Target/ARM/ARMConstantPoolValue.cpp	(working copy)
@@ -84,12 +84,26 @@
 }
 
 void ARMConstantPoolValue::print(raw_ostream &O) const {
+  // NOTE: this is not used for codegeneration, moreover
+  //       some of the logic is replicated in
+  //       EmitMachineConstantPoolValue()
+
   if (GV)
     O << GV->getName();
   else
     O << S;
-  if (isNonLazyPointer()) O << "$non_lazy_ptr";
-  else if (isStub()) O << "$stub";
+
+  if (isNonLazyPointer()) {
+    O << "$non_lazy_ptr";
+  } else if (isStub()) {
+    O << "$stub";
+  } else if (isDataSegmentJumpTable()) {
+    // requires synchronization with ARMAsmPrinter.cpp
+    O << "$jumptable$" << LabelId;
+  } else {
+    assert(isValue() && "unknown CP kind");
+  }
+
   if (Modifier) O << "(" << Modifier << ")";
   if (PCAdjust != 0) {
     O << "-(LPC" << LabelId << "+" << (unsigned)PCAdjust;

From evan.cheng at apple.com  Wed Jun 24 14:27:30 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Wed, 24 Jun 2009 14:27:30 -0700
Subject: [LLVMdev] lli aborts on arm QEMU
In-Reply-To: <4A41DBB7.3030303@free.fr>
References: <20090623192606.0D42BBE407E@ws1-9.us4.outblaze.com>
	<4A41DBB7.3030303@free.fr>
Message-ID: <86CCBCEA-9867-41E2-BFE7-AD30D1A8E12D@apple.com>

ARM JIT was able to run the entire llvm test suite when I left it a  
few months ago. "Hello world" should definitely work. It's possible it  
has been broken. But It's equally as likely llvm itself is miscompiled.

There really isn't a way to tell unless you debug it. Can you run it  
in gdb? What happens if you run it like this:
"lli -debug-only=jit hello2.bc".

Also, try -march=arm (if the bitcode file doesn't have the right  
triplet). Also add -mattr=+v6, anything under v6 is not well tested  
(although I am pretty sure v5 works).

Evan

On Jun 24, 2009, at 12:54 AM, Duncan Sands wrote:

> hannibal hannibal wrote:
>> I get the following error when I try to run arm lli on QEMU:
>>
>> lli: llvm-arm/src/llvm/include/llvm/ADT/ilist.h:197: typename  
>> bidirectional_iterator<NodeTy, int>::reference  
>> llvm::ilist_iterator<NodeTy>::operator*() const [with NodeTy =  
>> llvm::RecyclerStruct]: Assertion `Traits::getNext(NodePtr) != 0 &&  
>> "Dereferencing end()!"' failed.
>> 0   lli 0x006abbfc
>> Stack dump:
>> 0.	Program arguments: ./lli hello2.bc
>> 1.	Running pass 'ARM Instruction Selection' on function '@main'
>> Aborted.
>>
>>
>> Is it a bug or I am doing something stupid?
>
> It sounds like a bug.  However ARM is moving fast at the moment, so
> you might want to try again in a few days time before opening a bug
> report.
>
> 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 evan.cheng at apple.com  Wed Jun 24 14:30:36 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Wed, 24 Jun 2009 14:30:36 -0700
Subject: [LLVMdev] make check where host != target
In-Reply-To: <305d6f60906240808v482a9442kd6ce7fa93f4046d3@mail.gmail.com>
References: <305d6f60906240808v482a9442kd6ce7fa93f4046d3@mail.gmail.com>
Message-ID: <62CBA840-C509-4498-B90A-29EE41917383@apple.com>

The dejagnu tests are mostly compile tests and / or grep'ing for  
patterns in generated code. It shouldn't matter if host != target.

Evan

On Jun 24, 2009, at 8:08 AM, Sandeep Patel wrote:

> Is make check supposed to work in cases where host != target? I'm
> seeing a ton of problems where the makefiles are testing $(OS) and
> trying to test the properties of the target OS, not the host OS.
>
> deep
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



From jon at ffconsultancy.com  Wed Jun 24 15:48:59 2009
From: jon at ffconsultancy.com (Jon Harrop)
Date: Wed, 24 Jun 2009 23:48:59 +0100
Subject: [LLVMdev] New HLVM examples
Message-ID: <200906242348.59350.jon@ffconsultancy.com>


HLVM is a garbage collected virtual machine built upon LLVM:

  http://forge.ocamlcore.org/projects/hlvm/

The development of HLVM was described in a series of three OCaml Journal 
articles that turned out to be among our most popular. Consequently, we have 
decided to run another series of related articles that build upon this 
foundation in order to develop complete compilers. The first article 
describes a compiler written in only 228 lines of code that can execute 
interesting programs:

  http://ocamlnews.blogspot.com/2009/06/compiler-development-part-1.html

For example, the compiler described in the article can execute the following 
OCaml-like program to print the Mandelbrot set:

# let rec pixel((n, zr, zi, cr, ci) : int * float * float * float * float) :
unit =
    if n = 65536 then print_char ' ' else
      if zr * zr + zi * zi >= 4.0 then print_char '.' else
        pixel(n+1, zr * zr - zi * zi + cr, 2.0 * zr * zi + ci, cr, ci);;
# let rec row((i, j, n) : int * int * int) : unit =
    if i>n then () else
      begin
        let cr = 2.0 * float_of_int i / float_of_int n - 1.5 in
        let ci = 2.0 * float_of_int j / float_of_int n - 1.0 in
        pixel(0, 0.0, 0.0, cr, ci);
        row(i+1, j, n)
      end;;
# let rec col((j, n) : int * int) : unit =
    if j>n then () else
      begin
        row(0, j, n);
        print_char '\n';
        col(j+1, n)
      end;;
# let rec mandelbrot(n : int) : unit =
    col(0, n);;
# mandelbrot 77;;

In particular, our compiler runs this program interactively 50x faster than
the OCaml top-level and 60% faster than native-code compiled OCaml!

The complete source code of HLVM and the example programs including this 
compiler are freely available under a BSD license and may be downloaded from 
HLVM's SVN repository as follows:

  svn checkout svn://svn.forge.ocamlcore.org/svnroot/hlvm

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e



From evan.cheng at apple.com  Wed Jun 24 14:43:50 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Wed, 24 Jun 2009 14:43:50 -0700
Subject: [LLVMdev] [llvm-commits] JITEventListener for eventual
	profiling and	maybe gdb support
In-Reply-To: <bb55930e0906241326l76299679hd7ee7b600d45bff5@mail.gmail.com>
References: <bb55930e0906241202s1e55634did93db40593beba28@mail.gmail.com>
	<bb55930e0906241326l76299679hd7ee7b600d45bff5@mail.gmail.com>
Message-ID: <62DFCB0E-A015-41DF-8D69-BEBFB77D9661@apple.com>

Hi Jeffrey,

This looks very good. Thanks. Some comments:

+/// JitSymbolEntry - Each function that is JIT compiled results in  
one of these
+/// being added to an array of symbols.  This indicates the name of  
the function
+/// as well as the address range it occupies.  This allows the client  
to map
+/// from a PC value to the name of the function.
+struct JitSymbolEntry {

A nitpick. Please rename it to "JITSymbolEntry" for naming consistency.

+
+// This is a public symbol so the performance tools can find it.
+JitSymbolTable *__jitSymbolTable;
+

Hmm. Is there a better solution? From what I can tell, the event  
listener is responsible for allocating symbol table memory so it  
effectively owns it. Can we register the address with the performance  
tools? We're pushing to be more thread safe.

+struct FunctionEmittedEvent {
+  // Indices are local to the RecordingJITEventListener, since the
+  // JITEventListener interface makes no guarantees about the order of
+  // calls between Listeners.
+  int Index;

Use "unsigned" instead of "int"? Can index ever be negative?

Evan

On Jun 24, 2009, at 1:26 PM, Jeffrey Yasskin wrote:

> Ack, sorry. I should have sent this to llvm-commits instead. :-P
> Followups there please.
>
> On Wed, Jun 24, 2009 at 12:02 PM, Jeffrey  
> Yasskin<jyasskin at google.com> wrote:
>> I intend to use this to support oprofile's ability to symbolize  
>> JITted
>> code through the interface described at
>> http://oprofile.sourceforge.net/doc/devel/jit-interface.html. I
>> believe the interface will also be useful for gdb support. I'm
>> considering adding some flags to the JITEventListener to let the JIT
>> avoid collecting information no listener is going to use, but I won't
>> do that until there's a need.
>>
>> I've added EmittedFunctionDetails in this patch so that I don't have
>> to change the NotifyFunctionEmitted() interface in a future patch. To
>> record line number information, oprofile wants an array of structs of
>> the form:
>>
>>  struct debug_line_info {
>>       unsigned long vma;
>>       unsigned int lineno;
>>       /* The filename format is unspecified, absolute path,  
>> relative etc. */
>>       char const * filename;
>>  };
>>
>> so I'll add enough information to produce that to the
>> EmittedFunctionDetails in a later patch.
>>
>> Chris mentioned that someone may want to extend this to fire events  
>> on
>> stub emission too.
>>
>> Let me know what you think.
>> Jeffrey
>>
> <event-listener.patch>_______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits



From echristo at apple.com  Wed Jun 24 14:46:58 2009
From: echristo at apple.com (Eric Christopher)
Date: Wed, 24 Jun 2009 14:46:58 -0700
Subject: [LLVMdev] [llvm-commits] JITEventListener for eventual
	profiling	and	maybe gdb support
In-Reply-To: <62DFCB0E-A015-41DF-8D69-BEBFB77D9661@apple.com>
References: <bb55930e0906241202s1e55634did93db40593beba28@mail.gmail.com>
	<bb55930e0906241326l76299679hd7ee7b600d45bff5@mail.gmail.com>
	<62DFCB0E-A015-41DF-8D69-BEBFB77D9661@apple.com>
Message-ID: <10F2DC61-03F0-4548-91B1-A1C0DD0FBB10@apple.com>


On Jun 24, 2009, at 2:43 PM, Evan Cheng wrote:

> +// This is a public symbol so the performance tools can find it.
> +JitSymbolTable *__jitSymbolTable;
> +
>
> Hmm. Is there a better solution? From what I can tell, the event
> listener is responsible for allocating symbol table memory so it
> effectively owns it. Can we register the address with the performance
> tools? We're pushing to be more thread safe.

This code is just a move of something already in llvm.  I'm currently  
bugging
the performance tools guys here for a better way to do this, and have  
hopes
of something reasonably soon I can add into llvm.  That said, as far  
as I can tell
from asking this code doesn't work with any performance tools at apple
and is off by default :)

-eric


From devang.patel at gmail.com  Wed Jun 24 16:12:56 2009
From: devang.patel at gmail.com (Devang Patel)
Date: Wed, 24 Jun 2009 16:12:56 -0700
Subject: [LLVMdev] Internal passes in LLVMC
In-Reply-To: <d17b77a40906241017k3751118ha6acc65e82de21a0@mail.gmail.com>
References: <d17b77a40906241017k3751118ha6acc65e82de21a0@mail.gmail.com>
Message-ID: <352a1fb20906241612y412e0cb8n8871d791d25de62d@mail.gmail.com>

On Wed, Jun 24, 2009 at 10:17 AM, Juan Carlos Martinez Santos <
juanc.martinez.santos at gmail.com> wrote:

> Hello,
>
> When I run llvm-gcc -emit-llvm hello.c -c -o hello.bc... what are the
> (default) passes that the driver is using? Where I can information about it?
> I want to examinate what are the sequences of passes that LLVM runs in each
> process.


Use -fdebug-pass-arguments or -fdebug-pass-structure on llvm-gcc command
line.
-
Devang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090624/95273a51/attachment.html>

From jon at ffconsultancy.com  Wed Jun 24 17:40:24 2009
From: jon at ffconsultancy.com (Jon Harrop)
Date: Thu, 25 Jun 2009 01:40:24 +0100
Subject: [LLVMdev] HLVM documentation
Message-ID: <200906250140.24139.jon@ffconsultancy.com>


The ocamldoc-generated documentation for HLVM is now available here:

  http://www.ffconsultancy.com/ocaml/hlvm/docs/

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e


From deeppatel1987 at gmail.com  Wed Jun 24 16:32:14 2009
From: deeppatel1987 at gmail.com (Sandeep Patel)
Date: Wed, 24 Jun 2009 16:32:14 -0700
Subject: [LLVMdev] make check where host != target
In-Reply-To: <62CBA840-C509-4498-B90A-29EE41917383@apple.com>
References: <305d6f60906240808v482a9442kd6ce7fa93f4046d3@mail.gmail.com>
	<62CBA840-C509-4498-B90A-29EE41917383@apple.com>
Message-ID: <305d6f60906241632h14ac2cd9of8d0f4d88717b99f@mail.gmail.com>

Indeed it doesn't matter until you get to the Feature and FrontendC
suites. I'd kinda like to test llvm-gcc along the way. :-)

deep

On Wed, Jun 24, 2009 at 2:30 PM, Evan Cheng<evan.cheng at apple.com> wrote:
> The dejagnu tests are mostly compile tests and / or grep'ing for
> patterns in generated code. It shouldn't matter if host != target.
>
> Evan
>
> On Jun 24, 2009, at 8:08 AM, Sandeep Patel wrote:
>
>> Is make check supposed to work in cases where host != target? I'm
>> seeing a ton of problems where the makefiles are testing $(OS) and
>> trying to test the properties of the target OS, not the host OS.
>>
>> deep
>> _______________________________________________
>> 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 eli.friedman at gmail.com  Wed Jun 24 17:18:23 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Thu, 25 Jun 2009 09:18:23 +0900
Subject: [LLVMdev] Replacing instruction in LLVM IR by an intrinsics
In-Reply-To: <op.uv1b4f2c0lgsd9@localhost.localdomain>
References: <op.uv1b4f2c0lgsd9@localhost.localdomain>
Message-ID: <f5aa3e9b0906241718n46b6ca6fhc05f77224f831fc8@mail.gmail.com>

On Thu, Jun 25, 2009 at 12:32 AM, ihusar<ihusar at fit.vutbr.cz> wrote:
>                //now i need to create an instruction that represents a call to a intrinsic
>                Function* FIntr = Intrinsic::getDeclaration(&M, Intrinsic::regread_i32);
>
>                // here it fails: void llvm::CallInst::init(llvm::Value*):
>                //Assertion `FTy->getNumParams() == 0 && "Calling a function with bad signature"' failed.
>                Instruction* Instr = CallInst::Create(FIntr);

You have to include the operands in the call to CallInst::Create.

-Eli



From jyasskin at google.com  Wed Jun 24 17:43:36 2009
From: jyasskin at google.com (Jeffrey Yasskin)
Date: Wed, 24 Jun 2009 17:43:36 -0700
Subject: [LLVMdev] [llvm-commits] JITEventListener for eventual
	profiling and maybe gdb support
In-Reply-To: <62DFCB0E-A015-41DF-8D69-BEBFB77D9661@apple.com>
References: <bb55930e0906241202s1e55634did93db40593beba28@mail.gmail.com>
	<bb55930e0906241326l76299679hd7ee7b600d45bff5@mail.gmail.com>
	<62DFCB0E-A015-41DF-8D69-BEBFB77D9661@apple.com>
Message-ID: <bb55930e0906241743u1a50fd2as33d638a1961817f6@mail.gmail.com>

On Wed, Jun 24, 2009 at 2:43 PM, Evan Cheng<evan.cheng at apple.com> wrote:
> Hi Jeffrey,
>
> This looks very good. Thanks. Some comments:
>
> +/// JitSymbolEntry - Each function that is JIT compiled results in
> one of these
> +/// being added to an array of symbols.  This indicates the name of
> the function
> +/// as well as the address range it occupies.  This allows the client
> to map
> +/// from a PC value to the name of the function.
> +struct JitSymbolEntry {
>
> A nitpick. Please rename it to "JITSymbolEntry" for naming consistency.

Done, although this is just a move.

> +
> +// This is a public symbol so the performance tools can find it.
> +JitSymbolTable *__jitSymbolTable;
> +
>
> Hmm. Is there a better solution? From what I can tell, the event
> listener is responsible for allocating symbol table memory so it
> effectively owns it. Can we register the address with the performance
> tools? We're pushing to be more thread safe.

As Eric said, this is just moving existing code, and it's #ifdef'ed
out. I'll let the Shark folks invent a better solution. :)

> +struct FunctionEmittedEvent {
> +  // Indices are local to the RecordingJITEventListener, since the
> +  // JITEventListener interface makes no guarantees about the order of
> +  // calls between Listeners.
> +  int Index;
>
> Use "unsigned" instead of "int"? Can index ever be negative?

Sure, it's unsigned now.

> On Jun 24, 2009, at 1:26 PM, Jeffrey Yasskin wrote:
>
>> Ack, sorry. I should have sent this to llvm-commits instead. :-P
>> Followups there please.
>>
>> On Wed, Jun 24, 2009 at 12:02 PM, Jeffrey
>> Yasskin<jyasskin at google.com> wrote:
>>> I intend to use this to support oprofile's ability to symbolize
>>> JITted
>>> code through the interface described at
>>> http://oprofile.sourceforge.net/doc/devel/jit-interface.html. I
>>> believe the interface will also be useful for gdb support. I'm
>>> considering adding some flags to the JITEventListener to let the JIT
>>> avoid collecting information no listener is going to use, but I won't
>>> do that until there's a need.
>>>
>>> I've added EmittedFunctionDetails in this patch so that I don't have
>>> to change the NotifyFunctionEmitted() interface in a future patch. To
>>> record line number information, oprofile wants an array of structs of
>>> the form:
>>>
>>>  struct debug_line_info {
>>>       unsigned long vma;
>>>       unsigned int lineno;
>>>       /* The filename format is unspecified, absolute path,
>>> relative etc. */
>>>       char const * filename;
>>>  };
>>>
>>> so I'll add enough information to produce that to the
>>> EmittedFunctionDetails in a later patch.
>>>
>>> Chris mentioned that someone may want to extend this to fire events
>>> on
>>> stub emission too.
>>>
>>> Let me know what you think.
>>> Jeffrey
>>>
>> <event-listener.patch>_______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: event-listener.patch
Type: text/x-diff
Size: 34384 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090624/18380581/attachment.patch>

From evan.cheng at apple.com  Wed Jun 24 17:48:01 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Wed, 24 Jun 2009 17:48:01 -0700
Subject: [LLVMdev] [llvm-commits] JITEventListener for
	eventual	profiling and maybe gdb support
In-Reply-To: <bb55930e0906241743u1a50fd2as33d638a1961817f6@mail.gmail.com>
References: <bb55930e0906241202s1e55634did93db40593beba28@mail.gmail.com>
	<bb55930e0906241326l76299679hd7ee7b600d45bff5@mail.gmail.com>
	<62DFCB0E-A015-41DF-8D69-BEBFB77D9661@apple.com>
	<bb55930e0906241743u1a50fd2as33d638a1961817f6@mail.gmail.com>
Message-ID: <0AF2D968-A659-4C21-AF19-CECD07F24D59@apple.com>

Thanks. Please commit.

Owen, just a FYI about __jitSymbolTable. I thought you should care  
because of your thread safe work.

Evan

On Jun 24, 2009, at 5:43 PM, Jeffrey Yasskin wrote:

> On Wed, Jun 24, 2009 at 2:43 PM, Evan Cheng<evan.cheng at apple.com>  
> wrote:
>> Hi Jeffrey,
>>
>> This looks very good. Thanks. Some comments:
>>
>> +/// JitSymbolEntry - Each function that is JIT compiled results in
>> one of these
>> +/// being added to an array of symbols.  This indicates the name of
>> the function
>> +/// as well as the address range it occupies.  This allows the  
>> client
>> to map
>> +/// from a PC value to the name of the function.
>> +struct JitSymbolEntry {
>>
>> A nitpick. Please rename it to "JITSymbolEntry" for naming  
>> consistency.
>
> Done, although this is just a move.
>
>> +
>> +// This is a public symbol so the performance tools can find it.
>> +JitSymbolTable *__jitSymbolTable;
>> +
>>
>> Hmm. Is there a better solution? From what I can tell, the event
>> listener is responsible for allocating symbol table memory so it
>> effectively owns it. Can we register the address with the performance
>> tools? We're pushing to be more thread safe.
>
> As Eric said, this is just moving existing code, and it's #ifdef'ed
> out. I'll let the Shark folks invent a better solution. :)
>
>> +struct FunctionEmittedEvent {
>> +  // Indices are local to the RecordingJITEventListener, since the
>> +  // JITEventListener interface makes no guarantees about the  
>> order of
>> +  // calls between Listeners.
>> +  int Index;
>>
>> Use "unsigned" instead of "int"? Can index ever be negative?
>
> Sure, it's unsigned now.
>
>> On Jun 24, 2009, at 1:26 PM, Jeffrey Yasskin wrote:
>>
>>> Ack, sorry. I should have sent this to llvm-commits instead. :-P
>>> Followups there please.
>>>
>>> On Wed, Jun 24, 2009 at 12:02 PM, Jeffrey
>>> Yasskin<jyasskin at google.com> wrote:
>>>> I intend to use this to support oprofile's ability to symbolize
>>>> JITted
>>>> code through the interface described at
>>>> http://oprofile.sourceforge.net/doc/devel/jit-interface.html. I
>>>> believe the interface will also be useful for gdb support. I'm
>>>> considering adding some flags to the JITEventListener to let the  
>>>> JIT
>>>> avoid collecting information no listener is going to use, but I  
>>>> won't
>>>> do that until there's a need.
>>>>
>>>> I've added EmittedFunctionDetails in this patch so that I don't  
>>>> have
>>>> to change the NotifyFunctionEmitted() interface in a future  
>>>> patch. To
>>>> record line number information, oprofile wants an array of  
>>>> structs of
>>>> the form:
>>>>
>>>>  struct debug_line_info {
>>>>       unsigned long vma;
>>>>       unsigned int lineno;
>>>>       /* The filename format is unspecified, absolute path,
>>>> relative etc. */
>>>>       char const * filename;
>>>>  };
>>>>
>>>> so I'll add enough information to produce that to the
>>>> EmittedFunctionDetails in a later patch.
>>>>
>>>> Chris mentioned that someone may want to extend this to fire events
>>>> on
>>>> stub emission too.
>>>>
>>>> Let me know what you think.
>>>> Jeffrey
>>>>
>>> <event- 
>>> listener.patch>_______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
> <event-listener.patch>_______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



From ihusar at fit.vutbr.cz  Thu Jun 25 03:36:35 2009
From: ihusar at fit.vutbr.cz (ihusar)
Date: Thu, 25 Jun 2009 12:36:35 +0200
Subject: [LLVMdev] Replacing instruction in LLVM IR by an intrinsics
In-Reply-To: <f5aa3e9b0906241718n46b6ca6fhc05f77224f831fc8@mail.gmail.com>
References: <op.uv1b4f2c0lgsd9@localhost.localdomain>
	<f5aa3e9b0906241718n46b6ca6fhc05f77224f831fc8@mail.gmail.com>
Message-ID: <op.uv2s27ro0lgsd9@localhost.localdomain>

On Thu, 25 Jun 2009 02:18:23 +0200, Eli Friedman <eli.friedman at gmail.com> wrote:

> On Thu, Jun 25, 2009 at 12:32 AM, ihusar<ihusar at fit.vutbr.cz> wrote:
>>                //now i need to create an instruction that represents a call to a intrinsic
>>                Function* FIntr = Intrinsic::getDeclaration(&M, Intrinsic::regread_i32);
>>
>>                // here it fails: void llvm::CallInst::init(llvm::Value*):
>>                //Assertion `FTy->getNumParams() == 0 && "Calling a function with bad signature"' failed.
>>                Instruction* Instr = CallInst::Create(FIntr);
>
> You have to include the operands in the call to CallInst::Create.
>
> -Eli


Hi, I created arguments as you told and now everything works fine. If someone would be interested, I am putting the code here.

Adam


void CGInstrOpRewriter::replaceByIntrinsic(Module& M, Instruction* instrToReplace, const Intrinsic::ID intrId, const int arg1, const int arg2)
{
	//create function and its arguments
	Function* FIntr = Intrinsic::getDeclaration(&M, intrId); 
	
	SmallVector<Value*, 2> Args(2);
	
	Args[0] = ConstantInt::get(Type::Int32Ty, arg1);  
	Args[1] = ConstantInt::get(Type::Int32Ty, arg2);
	
	//now create and replace original instruction
	Instruction* IntrI = CallInst::Create(FIntr, Args.begin(), Args.end());
	
	ReplaceInstWithInst(instrToReplace, IntrI);
}

bool CGInstrOpRewriter::runOnModule(Module &M) 
{
	if (!bLoaded)
	{
		llvm::cerr << "CG: Error: Ignoring module\n"; //should not happen
		return false;
	}
	
	//for each function in module
	for(Module::iterator FuncIt = M.getFunctionList().begin(); FuncIt != M.getFunctionList().end(); FuncIt++)
	{
		Function* F = FuncIt;
	
		llvm::cerr << "Original ---- \n" << *F << "\n";
		
		//and for each instruction of a function
		for (inst_iterator It = inst_begin(F), E = inst_end(F); It != E; ++It)
		{
			//previous iterator
			inst_iterator PrevIt; 
			bool bFirst = false;
			if (It == inst_begin(F))
			{
				bFirst = true;
			}
			else
			{
				PrevIt = It;
				--PrevIt;
			}
			
			Instruction* CurrI = &(*It);

			llvm::cerr << "Processing " << *CurrI << "\n";
			
			if (isa<LoadInst>(CurrI))
			{

				//replace - intrinsics ID (from Intrinsics.def) and some int arguments
				replaceByIntrinsic(M, CurrI, Intrinsic::regread_i32, 1, 2);
				
				//renew iterator because we removed previous instruction to which it was pointing
				if (!bFirst)
				{
					It = ++PrevIt;
				}
				else
				{
					It = ++inst_begin(F);
				}
			}
			
		}

		llvm::cerr << "Modified ---- \n" << *F << "\n";
	}

	return true;
}




From sebastian.redl at getdesigned.at  Thu Jun 25 07:10:45 2009
From: sebastian.redl at getdesigned.at (Sebastian Redl)
Date: Thu, 25 Jun 2009 16:10:45 +0200
Subject: [LLVMdev] [cfe-dev] LLVM frontend supporting arbitrary
 bit-width integral datatypes
In-Reply-To: <4A4228B8.8040005@free.fr>
References: <op.uuwe38tn0lgsd9@localhost.localdomain>
	<4A2834A8.2080402@tut.fi>	<op.uv04gua50lgsd9@localhost.localdomain>
	<4A4228B8.8040005@free.fr>
Message-ID: <4A438565.7040307@getdesigned.at>

Duncan Sands wrote:
> Hi Adam,
>
>   
>> One problem, I was trying to solve was, that I need to declare variables of let's say 5-bit width like  'i5 var',
>> the maximal bit-width may be limited to 64 bits. I need such variables to represent instruction's operands,
>> example is at the end this message.
>>     
>
> any standard compliant C compiler supports i5, believe it or not.
>
> Try this:
>
> #include <stdio.h>
>
> struct i3 { int i:3; };
>
> int main(void) {
>    struct i3 A, B, C;
>
>    A.i = 2;
>    B.i = 3;
>    C.i = A.i + B.i;
>    printf("%d + %d = %d\n", A.i, B.i, C.i);
>    return 0;
> }
>
> I get:
> 2 + 3 = -3
> which is correct for i3 arithmetic!
> There might be some problems with signed vs unsigned bitfields,
> depending on the compiler.
>   
You're producing a signed overflow, which is simply undefined behavior.
Unsigned overflow is well-defined, even for bitfields, but signed is not.

Sebastian


From baldrick at free.fr  Thu Jun 25 07:16:07 2009
From: baldrick at free.fr (Duncan Sands)
Date: Thu, 25 Jun 2009 16:16:07 +0200
Subject: [LLVMdev] [cfe-dev] LLVM frontend supporting arbitrary
 bit-width integral datatypes
In-Reply-To: <4A438565.7040307@getdesigned.at>
References: <op.uuwe38tn0lgsd9@localhost.localdomain>
	<4A2834A8.2080402@tut.fi>	<op.uv04gua50lgsd9@localhost.localdomain>
	<4A4228B8.8040005@free.fr> <4A438565.7040307@getdesigned.at>
Message-ID: <4A4386A7.1040309@free.fr>

Hi Sebastian,

> You're producing a signed overflow, which is simply undefined behavior.
> Unsigned overflow is well-defined, even for bitfields, but signed is not.

that's true, here's an unsigned version (outputs 5 + 5 = 2):

#include <stdio.h>

struct i3 { unsigned i:3; };

int main(void) {
   struct i3 A, B, C;

   A.i = 5;
   B.i = 5;
   C.i = A.i + B.i;
   printf("%d + %d = %d\n", A.i, B.i, C.i);
   return 0;
}
Ciao,

Duncan.


From kapilanand2 at gmail.com  Thu Jun 25 10:49:36 2009
From: kapilanand2 at gmail.com (kapil anand)
Date: Thu, 25 Jun 2009 13:49:36 -0400
Subject: [LLVMdev] Structure Returns
Message-ID: <9f741d560906251049x5c970ab1ge044126bde240516@mail.gmail.com>

Hi,

In my LLVM IR I am returning a structure from a function but it gave me an
assertion failure when I was trying to compile the resulting bitcode.

Specifically, I had following function definition


define {i32,i32,i32} @func(i32 a)
{
.....
ret {i32,i32,i32} %retStruct
}


llc gave me following assertion failure:

Return operand#2 has unhandled type i32  in AnalyzeReturn function

On digging out from LLVM website, I found

"Note that the code generator does not yet fully support large return
values. The specific sizes that are currently supported are dependent on the
target. For integers, on 32-bit targets the limit is often 64 bits, and on
64-bit targets the limit is often 128 bits. For aggregate types, the current
limits are dependent on the element types; for example targets are often
limited to 2 total integer elements and 2 total floating-point elements."

So, does this mean that I can't have a return type with more than two
integers? Is there any other way to support longer return structure?

-- Kapil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090625/3ba55e74/attachment.html>

From juanc.martinez.santos at gmail.com  Thu Jun 25 11:04:17 2009
From: juanc.martinez.santos at gmail.com (Juan Carlos Martinez Santos)
Date: Thu, 25 Jun 2009 14:04:17 -0400
Subject: [LLVMdev] Problems with lli and hello.c
Message-ID: <d17b77a40906251104t3bfdd7dfiffdf1b04fbdd9b1@mail.gmail.com>

Hello,

I just install the new newest version of LLVM. When I ran the hello.c
example I got the below message. Somebody has an idea what is wrong? The
problem is just with lli, the other commands worked as I expected.

**********************
:~/LLVM/my-test$ lli hello.bc
Tried to execute an unknown external function: i32 (i8*)* puts
0   lli 0x0861fab8
Stack dump:
0.    Program arguments: lli hello.bc
Aborted
**********************

Thanks in advance.

-- 
Juan Carlos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090625/a227beed/attachment.html>

From jyasskin at google.com  Thu Jun 25 11:37:04 2009
From: jyasskin at google.com (Jeffrey Yasskin)
Date: Thu, 25 Jun 2009 11:37:04 -0700
Subject: [LLVMdev] Structure Returns
In-Reply-To: <9f741d560906251049x5c970ab1ge044126bde240516@mail.gmail.com>
References: <9f741d560906251049x5c970ab1ge044126bde240516@mail.gmail.com>
Message-ID: <bb55930e0906251137p5e98e2f5ie593fcc307454531@mail.gmail.com>

On Thu, Jun 25, 2009 at 10:49 AM, kapil anand<kapilanand2 at gmail.com> wrote:
> Hi,
>
> In my LLVM IR I am returning a structure from a function but it gave me an
> assertion failure when I was trying to compile the resulting bitcode.
>
> Specifically, I had following function definition
>
>
> define {i32,i32,i32} @func(i32 a)
> {
> .....
> ret {i32,i32,i32} %retStruct
> }
>
>
> llc gave me following assertion failure:
>
> Return operand#2 has unhandled type i32  in AnalyzeReturn function
>
> On digging out from LLVM website, I found
>
> "Note that the code generator does not yet fully support large return
> values. The specific sizes that are currently supported are dependent on the
> target. For integers, on 32-bit targets the limit is often 64 bits, and on
> 64-bit targets the limit is often 128 bits. For aggregate types, the current
> limits are dependent on the element types; for example targets are often
> limited to 2 total integer elements and 2 total floating-point elements."
>
> So, does this mean that I can't have a return type with more than two
> integers? Is there any other way to support longer return structure?

That's what it means (at least until someone like you contributes a
patch to support larger return structs). To work around it, imitate
what the C compiler does.

Try typing:

struct Big {
 int a, b, c;
};

struct Big foo() {
  struct Big result = {1, 2, 3};
  return result;
}


into http://llvm.org/demo/.



From samuraileumas at yahoo.com  Thu Jun 25 11:44:02 2009
From: samuraileumas at yahoo.com (Samuel Crow)
Date: Thu, 25 Jun 2009 11:44:02 -0700 (PDT)
Subject: [LLVMdev] Problems with lli and hello.c
In-Reply-To: <d17b77a40906251104t3bfdd7dfiffdf1b04fbdd9b1@mail.gmail.com>
References: <d17b77a40906251104t3bfdd7dfiffdf1b04fbdd9b1@mail.gmail.com>
Message-ID: <692939.41571.qm@web62004.mail.re1.yahoo.com>

Jello Juan,

The interpreter is quite useless in its current state.  Try using a JIT compiler for you computer from the lli command and it should work.

--Sam


>
>From: Juan Carlos Martinez Santos <juanc.martinez.santos at gmail.com>
>To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
>Sent: Thursday, June 25, 2009 1:04:17 PM
>Subject: [LLVMdev] Problems with lli and hello.c
>
>>Hello,
>
>I just install the new newest version of LLVM. When I ran the hello.c example I got the below message. Somebody has an idea what is wrong? The problem is just with lli, the other commands worked as I expected.
>
>**********************
>:~/LLVM/my-test$ lli hello.bc
>Tried to execute an unknown external function: i32 (i8*)* puts
>0   lli 0x0861fab8
>Stack dump:
>0.    Program arguments: lli hello.bc 
>Aborted
>**********************
>
>Thanks in advance.
>
>-- 
>Juan Carlos 
>


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090625/2d073abc/attachment.html>

From juanc.martinez.santos at gmail.com  Thu Jun 25 12:04:51 2009
From: juanc.martinez.santos at gmail.com (Juan Carlos Martinez Santos)
Date: Thu, 25 Jun 2009 15:04:51 -0400
Subject: [LLVMdev] Problems with lli and hello.c
In-Reply-To: <692939.41571.qm@web62004.mail.re1.yahoo.com>
References: <d17b77a40906251104t3bfdd7dfiffdf1b04fbdd9b1@mail.gmail.com>
	<692939.41571.qm@web62004.mail.re1.yahoo.com>
Message-ID: <d17b77a40906251204n5496b973i1f3caf1c1e176bc7@mail.gmail.com>

Thanks.

On Thu, Jun 25, 2009 at 2:44 PM, Samuel Crow <samuraileumas at yahoo.com>wrote:

> Jello Juan,
>
> The interpreter is quite useless in its current state.  Try using a JIT
> compiler for you computer from the lli command and it should work.
>
> --Sam
>
>
> *From:* Juan Carlos Martinez Santos <juanc.martinez.santos at gmail.com>
> *To:* LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> *Sent:* Thursday, June 25, 2009 1:04:17 PM
> *Subject:* [LLVMdev] Problems with lli and hello.c
>
> Hello,
>
> I just install the new newest version of LLVM. When I ran the hello.c
> example I got the below message. Somebody has an idea what is wrong? The
> problem is just with lli, the other commands worked as I expected.
>
> **********************
> :~/LLVM/my-test$ lli hello.bc
> Tried to execute an unknown external function: i32 (i8*)* puts
> 0   lli 0x0861fab8
> Stack dump:
> 0.    Program arguments: lli hello.bc
> Aborted
> **********************
>
> Thanks in advance.
>
> --
> Juan Carlos
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>


-- 
Juan Carlos Martínez Santos
242 Foster Drive Apt H
Colonial Townhouse Apartments
Willimantic, CT 06226-1538
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090625/209a77e3/attachment.html>

From artjom.kochtchi at googlemail.com  Thu Jun 25 14:05:36 2009
From: artjom.kochtchi at googlemail.com (Artjom K.)
Date: Thu, 25 Jun 2009 14:05:36 -0700 (PDT)
Subject: [LLVMdev]  Inserting nodes into SelectionDAG (X86)
Message-ID: <24211066.post@talk.nabble.com>


Greetings,

I am rather new to LLVM, so please excuse my limited knowledge about it.

Currently I am trying to modify the X86TargetLowering::LowerCALL method by
inserting additional instructions before the call.
As far as I understand, nodes are created by calling the getNode method on
the DAG. If, for example, I insert the following code

  Ops.push_back(Chain);
  Chain = DAG.getNode(ISD::TRAP, DAG.getVTList(MVT::Other), &Ops[0],
Ops.size());

then an X86 instruction (namely ud2) appears in the output files compiled by
llc.
So, is my understanding correct that
1) the Chain determines the ordering of the nodes?
2) the second parameter is a set of return types, i. e. in my example,
MVT::Other says that a Chain object will be returned?

Now, as soon as I try to generate more complex instructions, I get lost.
Say, I want to insert the following instruction

  mov   eax, 42

then the best I can come up with is

  Ops.push_back(Chain);
  Ops.push_back(DAG.getRegister(X86::EAX, MVT::i32));
  Ops.push_back(DAG.getConstant(42, MVT::i32));
  Chain = DAG.getNode(X86::MOV32ri, DAG.getVTList(MVT::Other), &Ops[0],
Ops.size());

But there are a few problems:
3) It seems I am not allowed to use concrete X86 instructions here (at least
that's what I think llc's error message "cannot yet select" could mean). Is
there an appropriate instruction in ISD? I can't find it...
4) Do I get the parameter passing right? Fooling around with other
expressions suggests that I get it wrong.
5) What exactly is the meaning of further result types? If I get the new
Chain object back, are the other results inside?

Could you help me out?

Sincerely,
Artjom Kochtchi
-- 
View this message in context: http://www.nabble.com/Inserting-nodes-into-SelectionDAG-%28X86%29-tp24211066p24211066.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.



From bob.wilson at apple.com  Thu Jun 25 15:17:19 2009
From: bob.wilson at apple.com (Bob Wilson)
Date: Thu, 25 Jun 2009 15:17:19 -0700
Subject: [LLVMdev] patch for llc/ARM: added mechanism to move
	switch	tables from .text -> .data; also cleanup and documentation
In-Reply-To: <8e3491100906241420h5facc3av280ae95d802f932c@mail.gmail.com>
References: <8e3491100906021826p4530f341xbb168d260c21342e@mail.gmail.com>
	<0453D1AB-FA5D-4947-BE50-02223AB8955B@apple.com>
	<8e3491100906070659k481580afk2d562a6c4a21a2a4@mail.gmail.com>
	<C2EC9000-8447-42CB-B3CD-5DB1652C356F@apple.com>
	<8e3491100906081442l3417b3e9nf3abeda39f8f2514@mail.gmail.com>
	<A81A63F1-DB89-45FD-A5DB-32E09A8C69EB@apple.com>
	<8e3491100906241420h5facc3av280ae95d802f932c@mail.gmail.com>
Message-ID: <A350319B-0930-40F7-B74B-AEC0FDBA8D01@apple.com>

Hi Robert,

Evan asked me to review this patch, and I have some questions about  
it.  I apologize for not following the discussion earlier and for  
hitting you with questions after you've already gone through several  
revisions.

LLVM provides some default behavior for handling jump tables, with the  
tables emitted separately from the code that uses them.  The ARM  
backend provides its own custom handling of jump tables so that it can  
emit them in-line with the text.  It seems to me that your patch  
changes the ARM backend to optionally handle jump tables in a way that  
is at least very similar to the default behavior, but you have  
implemented it without using the existing code.  Did you consider  
implementing it using the LLVM defaults?

Using TargetAsmInfo::JumpTableDataSection is one piece of that, but  
there is more.  As a start, you could change  
ARMJITInfo::hasCustomJumpTables and the "Custom" argument to  
setOperationAction for ISD::BR_JT in the ARMTargetLowering constructor  
to be conditional on your new flag.  I'm sure there is more required  
than that, but maybe that will get you started.

Otherwise, there are some problems with your custom handling for out- 
of-line jump tables.  The most serious of these is in  
ARMAsmPrinter::printJTBlockOperand: for out-of-line jump tables, you  
emit a ".text" directive to switch back to the text section.  If the  
current section is not ".text", however, this will break.  I believe  
you ought to use SwitchToTextSection instead.  Earlier in that same  
method, I think you should also use SwitchToDataSection and  
EmitAlignment.  But, again, rather than tweaking this code, I would  
prefer to find a way to use the existing LLVM code for this.

Why did you change the default value for JumpTableDataSection?  Jump  
tables really should not go into .data.  That is a security hole.   
They should be read-only.

When you create global symbols for the jump tables, you specify a ".T"  
name:

	new ARMConstantPoolValue(".T", Num, ARMCP::CPDataSegmentJumpTable);

Why ".T"?

And, by the way, I noticed that you removed a "blank" comment line in  
ARMISelLowering.h.  I think I have done that myself, but I recently  
discovered that the extra lines are intentional.  Doxygen recognizes C+ 
+ comments beginning with 3 slashes but you have to have at least 2  
lines of them or doxygen will not recognize them.

On Jun 24, 2009, at 2:20 PM, robert muth wrote:

> Evan:
>
> Sorry for the late follow up, I was out of town last week.
> Enclosed please find the updated patch including all
> your suggestions and a dejagnus test.
>
> Robert
>
> On Thu, Jun 11, 2009 at 2:27 PM, Evan Cheng <evan.cheng at apple.com>  
> wrote:
>
> On Jun 8, 2009, at 2:42 PM, robert muth wrote:
>
> > On Sun, Jun 7, 2009 at 11:53 PM, Evan Cheng <evan.cheng at apple.com>
> > wrote:
> >>
> >> On Jun 7, 2009, at 6:59 AM, robert muth wrote:
> >>
> >>> On Sat, Jun 6, 2009 at 4:51 PM, Evan Cheng<evan.cheng at apple.com>
> >>> wrote:
> >>>> +cl::opt<std::string> FlagJumpTableSection("jumptable-section",
> >>>> +
> >>>> cl::init(".data.jtab"));
> >>>> +
> >>>
> >>> I thought it would be nice to group all the jumptables together.
> >>> But as long as it stays configurable, I am fine to change the
> >>> default
> >>> to ".data".
> >>
> >> There is already a TargetAsmInfo::JumpTableDataSection. Why not  
> just
> >> use that?
> >
> > Nice find. I will use that and possible change the current setting,
> > ".const", if it does not work,
> >
> >>>
> >>>> Is this necessary? Why not just put it in the normal data  
> section?
> >>>> Also "outline" jumptable seems like a strange term. Can you think
> >>>> of
> >>>> something else?
> >>>
> >>>
> >>> Yes, that is a tough one. How about "NonInline" instead.
> >>
> >> Or "OutOfLine"?
> >
> > That works for me.
> >
> >> Please add a test case as well. Thanks,
> >
> > I am not sure how to go about testing.
>
> For this please just add a test case to the llvm dejagnu tests.
>
> thanks,
>
> Evan
>
> >
> > I have  a script that compiles a bunch of test
> > programs (gnu c torture test, etc.) and then runs the executables
> > on qemu.  I run this script with and without my flags and
> > make sure that I do not introduce any new problems
> > -- there are currently plenty of vararg issues.
> >
> > I was thinking of sending this script to the list
> > or maybe checking it into the llvm tree.
> >
> > The key is that whatever tests there are they should just
> > be run with and without the new flag.
> > How do you run backend tests?
> >
> > Robert
> >
> >
> >
> >
> >> Evan
> >>
> >>>
> >>> Robert
> >>>
> >>>> Thanks,
> >>>> Evan
> >>>>
> >>>> Sent from my iPhone
> >>>> On Jun 2, 2009, at 6:26 PM, robert muth <robert at muth.org> wrote:
> >>>>
> >>>> Hi:
> >>>>
> >>>> This is my first patch submission. Hopefully, this is the proper
> >>>> the
> >>>> protocol.
> >>>> Attached is a patch for the llc ARM backend:
> >>>>
> >>>> Added mechanism to generate switch table in a data section
> >>>> rather than having it interleaved with the code.
> >>>> This is controlled by command line flags and off by default.
> >>>> Also, tried to document and improve the code where I modified it.
> >>>>
> >>>> Robert
> >>>>
> >>>> <llc.patch.txt>
> >>>>
> >>>> _______________________________________________
> >>>> 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
> >>>>
> >>>>
> >>>
> >>> _______________________________________________
> >>> 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
> >>
> >
> > _______________________________________________
> > 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
>
> <llc.patch.2.txt>_______________________________________________
> 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.llvm.org/pipermail/llvm-dev/attachments/20090625/c6d93956/attachment.html>

From natebegeman at me.com  Thu Jun 25 15:40:08 2009
From: natebegeman at me.com (Nate Begeman)
Date: Thu, 25 Jun 2009 15:40:08 -0700
Subject: [LLVMdev] killing vicmp and vfcmp
In-Reply-To: <1DC9D28B-7ADE-4036-B542-20E56CB3CE9B@apple.com>
References: <4A41AF32.2040106@mxc.ca> <4A41DA12.90106@free.fr>
	<1DC9D28B-7ADE-4036-B542-20E56CB3CE9B@apple.com>
Message-ID: <95672B13-E7C5-45A3-B41B-B15A6A908FE3@me.com>


On Jun 24, 2009, at 10:02 AM, Chris Lattner wrote:

>
> On Jun 24, 2009, at 12:47 AM, Duncan Sands wrote:
>
>> Hi Nick,
>>
>>> Now that icmp and fcmp have supported returning vectors of i1 for a
>>> while,
>>
>> the code generators don't know how to codegen vectors of i1, so does
>> this actually work?
>
> No, but there are no clients of them yet.

What's the proposed replacement that will be pattern-matched to the  
vector comparison instructions in AltiVec, SSE, and NEON?

Nate



From gohman at apple.com  Thu Jun 25 16:31:08 2009
From: gohman at apple.com (Dan Gohman)
Date: Thu, 25 Jun 2009 16:31:08 -0700
Subject: [LLVMdev] Inserting nodes into SelectionDAG (X86)
In-Reply-To: <24211066.post@talk.nabble.com>
References: <24211066.post@talk.nabble.com>
Message-ID: <07E3436A-6277-4CD3-B44D-D7F2A9BA2675@apple.com>


On Jun 25, 2009, at 2:05 PM, Artjom K. wrote:


>
> Greetings,
>
> I am rather new to LLVM, so please excuse my limited knowledge about  
> it.
>
> Currently I am trying to modify the X86TargetLowering::LowerCALL  
> method by
> inserting additional instructions before the call.
> As far as I understand, nodes are created by calling the getNode  
> method on
> the DAG. If, for example, I insert the following code
>
>  Ops.push_back(Chain);
>  Chain = DAG.getNode(ISD::TRAP, DAG.getVTList(MVT::Other), &Ops[0],
> Ops.size());
>
> then an X86 instruction (namely ud2) appears in the output files  
> compiled by
> llc.
> So, is my understanding correct that
> 1) the Chain determines the ordering of the nodes?

Yes.

> 2) the second parameter is a set of return types, i. e. in my example,
> MVT::Other says that a Chain object will be returned?'

Yes.

>
> Now, as soon as I try to generate more complex instructions, I get  
> lost.
> Say, I want to insert the following instruction
>
>  mov   eax, 42
>
> then the best I can come up with is
>
>  Ops.push_back(Chain);
>  Ops.push_back(DAG.getRegister(X86::EAX, MVT::i32));
>  Ops.push_back(DAG.getConstant(42, MVT::i32));
>  Chain = DAG.getNode(X86::MOV32ri, DAG.getVTList(MVT::Other), &Ops[0],
> Ops.size());
>
> But there are a few problems:
> 3) It seems I am not allowed to use concrete X86 instructions here  
> (at least
> that's what I think llc's error message "cannot yet select" could  
> mean). Is
> there an appropriate instruction in ISD? I can't find it...

Yes. It seems the opcode you want here is ISD::CopyToReg.

> 4) Do I get the parameter passing right? Fooling around with other
> expressions suggests that I get it wrong.

It looks like you have the right idea. For CopyToReg nodes,
there's a special getCopyToReg accessor for convenience.

> 5) What exactly is the meaning of further result types? If I get the  
> new
> Chain object back, are the other results inside?

SDNodes may have multiple results. For example, a LOAD node
has two results: the Chain that indicates ordering with
respect to other operations which may modify memory, and
the actual loaded value. Individual results of an SDNode
are identified with SDValue objects.

Dan



From david_goodwin at apple.com  Thu Jun 25 16:38:33 2009
From: david_goodwin at apple.com (David Goodwin)
Date: Thu, 25 Jun 2009 16:38:33 -0700
Subject: [LLVMdev] bitwise AND selector node not commutative?
Message-ID: <FFC5A32B-B2BA-4C99-9CAB-6908F7952053@apple.com>

Using the Thumb-2 target we see that ORN ( a | ^b) and BIC (a & ^b)  
have similar patterns, as we would expect:

defm t2BIC  : T2I_bin_irs<"bic", BinOpFrag<(and node:$LHS, (not node: 
$RHS))>>;
defm t2ORN  : T2I_bin_irs<"orn", BinOpFrag<(or  node:$LHS, (not node: 
$RHS))>>;

Compiling the following three works as expected:

    %tmp1 = xor i32 4294967295, %b ;   %tmp2 = or i32 %a, %tmp1   -->   
	orn r0, r0, r1
    %tmp1 = xor i32 4294967295, %b ;   %tmp2 = or i32 %tmp1, %a   -- 
 >    orn r0, r0, r1
    %tmp = xor i32 %b, 4294967295  ;   %tmp1 = and i32 %a, %tmp   -- 
 >    bic r0, r0, r1

But this doesn't:

    %tmp = xor i32 %b, 4294967295  ;   %tmp1 = and i32 %tmp, %a   -- 
 >    eor r1, r1, #4294967295 ; and r0, r1, r0

On the surface it seems that the selector is not commuting the AND  
operands. I've attached the complete test files. I can take a look but  
I need a pointer to get started.

David

  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090625/0706b1cb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RM_20_BIC.ll
Type: application/octet-stream
Size: 364 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090625/0706b1cb/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090625/0706b1cb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RM_112_ORN.ll
Type: application/octet-stream
Size: 366 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090625/0706b1cb/attachment-0001.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090625/0706b1cb/attachment-0002.html>

From evan.cheng at apple.com  Thu Jun 25 18:06:50 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Thu, 25 Jun 2009 18:06:50 -0700
Subject: [LLVMdev] bitwise AND selector node not commutative?
In-Reply-To: <FFC5A32B-B2BA-4C99-9CAB-6908F7952053@apple.com>
References: <FFC5A32B-B2BA-4C99-9CAB-6908F7952053@apple.com>
Message-ID: <35EBBC0A-DD16-4B9A-844F-9794CFC6FFB9@apple.com>


On Jun 25, 2009, at 4:38 PM, David Goodwin wrote:

> Using the Thumb-2 target we see that ORN ( a | ^b) and BIC (a & ^b)  
> have similar patterns, as we would expect:
>
> defm t2BIC  : T2I_bin_irs<"bic", BinOpFrag<(and node:$LHS, (not node: 
> $RHS))>>;
> defm t2ORN  : T2I_bin_irs<"orn", BinOpFrag<(or  node:$LHS, (not node: 
> $RHS))>>;
>
> Compiling the following three works as expected:
>
>    %tmp1 = xor i32 4294967295, %b ;   %tmp2 = or i32 %a, %tmp1   -- 
> >  	orn r0, r0, r1
>    %tmp1 = xor i32 4294967295, %b ;   %tmp2 = or i32 %tmp1, %a   -- 
> >    orn r0, r0, r1
>    %tmp = xor i32 %b, 4294967295  ;   %tmp1 = and i32 %a, %tmp   -- 
> >    bic r0, r0, r1
>
> But this doesn't:
>
>    %tmp = xor i32 %b, 4294967295  ;   %tmp1 = and i32 %tmp, %a   -- 
> >    eor r1, r1, #4294967295 ; and r0, r1, r0
>
> On the surface it seems that the selector is not commuting the AND  
> operands. I've attached the complete test files. I can take a look  
> but I need a pointer to get started.

No, isel is trying to commute the AND. See ARMGenDAGISel.inc (auto- 
generated by tablegen):

     // Pattern: (and:i32 GPR:i32:$lhs, (xor:i32 t2_so_reg:i32:$rhs,  
(imm:i32)<<P:Predicate_immAllOnes>>))
     // Emits: (t2BICrs:i32 GPR:i32:$lhs, t2_so_reg:i32:$rhs)
     // Pattern complexity = 19  cost = 1  size = 0
     {
       ..
     }


     // Pattern: (and:i32 (xor:i32 t2_so_reg:i32:$rhs, (imm:i32) 
<<P:Predicate_immAllOnes>>), GPR:i32:$lhs)
     // Emits: (t2BICrs:i32 GPR:i32:$lhs, t2_so_reg:i32:$rhs)
     // Pattern complexity = 19  cost = 1  size = 0
     {
      ...
      }

The second one is the commuted version. Looks like the issue is in  
SelectThumb2ShifterOperandReg.

Evan


>
> David
>
> <RM_20_BIC.ll>
> <RM_112_ORN.ll>
>
> _______________________________________________
> 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.llvm.org/pipermail/llvm-dev/attachments/20090625/3d9df62b/attachment.html>

From evan.cheng at apple.com  Thu Jun 25 18:09:49 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Thu, 25 Jun 2009 18:09:49 -0700
Subject: [LLVMdev] bitwise AND selector node not commutative?
In-Reply-To: <35EBBC0A-DD16-4B9A-844F-9794CFC6FFB9@apple.com>
References: <FFC5A32B-B2BA-4C99-9CAB-6908F7952053@apple.com>
	<35EBBC0A-DD16-4B9A-844F-9794CFC6FFB9@apple.com>
Message-ID: <1E5D7A6B-494D-46BD-8343-A7805C0C3BA1@apple.com>


On Jun 25, 2009, at 6:06 PM, Evan Cheng wrote:

>
> On Jun 25, 2009, at 4:38 PM, David Goodwin wrote:
>
>> Using the Thumb-2 target we see that ORN ( a | ^b) and BIC (a & ^b)  
>> have similar patterns, as we would expect:
>>
>> defm t2BIC  : T2I_bin_irs<"bic", BinOpFrag<(and node:$LHS, (not  
>> node:$RHS))>>;
>> defm t2ORN  : T2I_bin_irs<"orn", BinOpFrag<(or  node:$LHS, (not  
>> node:$RHS))>>;
>>
>> Compiling the following three works as expected:
>>
>>    %tmp1 = xor i32 4294967295, %b ;   %tmp2 = or i32 %a, %tmp1   -- 
>> >  	orn r0, r0, r1
>>    %tmp1 = xor i32 4294967295, %b ;   %tmp2 = or i32 %tmp1, %a   -- 
>> >    orn r0, r0, r1
>>    %tmp = xor i32 %b, 4294967295  ;   %tmp1 = and i32 %a, %tmp   -- 
>> >    bic r0, r0, r1
>>
>> But this doesn't:
>>
>>    %tmp = xor i32 %b, 4294967295  ;   %tmp1 = and i32 %tmp, %a   -- 
>> >    eor r1, r1, #4294967295 ; and r0, r1, r0
>>
>> On the surface it seems that the selector is not commuting the AND  
>> operands. I've attached the complete test files. I can take a look  
>> but I need a pointer to get started.
>
> No, isel is trying to commute the AND. See ARMGenDAGISel.inc (auto- 
> generated by tablegen):
>
>     // Pattern: (and:i32 GPR:i32:$lhs, (xor:i32 t2_so_reg:i32:$rhs,  
> (imm:i32)<<P:Predicate_immAllOnes>>))
>     // Emits: (t2BICrs:i32 GPR:i32:$lhs, t2_so_reg:i32:$rhs)
>     // Pattern complexity = 19  cost = 1  size = 0
>     {
>       ..
>     }
>
>
>     // Pattern: (and:i32 (xor:i32 t2_so_reg:i32:$rhs, (imm:i32) 
> <<P:Predicate_immAllOnes>>), GPR:i32:$lhs)
>     // Emits: (t2BICrs:i32 GPR:i32:$lhs, t2_so_reg:i32:$rhs)
>     // Pattern complexity = 19  cost = 1  size = 0
>     {
>      ...
>      }
>
> The second one is the commuted version. Looks like the issue is in  
> SelectThumb2ShifterOperandReg.

Ugh. It should try to match t2BICrr. But someone tblgen is not  
generating the commuted version. Very strange. I'm take a look.

Evan

>
> Evan
>
>
>>
>> David
>>
>> <RM_20_BIC.ll>
>> <RM_112_ORN.ll>
>>
>> _______________________________________________
>> 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.llvm.org/pipermail/llvm-dev/attachments/20090625/2b47d7a8/attachment.html>

From evan.cheng at apple.com  Thu Jun 25 23:00:22 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Thu, 25 Jun 2009 23:00:22 -0700
Subject: [LLVMdev] bitwise AND selector node not commutative?
In-Reply-To: <1E5D7A6B-494D-46BD-8343-A7805C0C3BA1@apple.com>
References: <FFC5A32B-B2BA-4C99-9CAB-6908F7952053@apple.com>
	<35EBBC0A-DD16-4B9A-844F-9794CFC6FFB9@apple.com>
	<1E5D7A6B-494D-46BD-8343-A7805C0C3BA1@apple.com>
Message-ID: <23AB5E17-AB75-4463-B1F8-B6BCEAA147F6@apple.com>

Fixed.

Evan

On Jun 25, 2009, at 6:09 PM, Evan Cheng wrote:

>
> On Jun 25, 2009, at 6:06 PM, Evan Cheng wrote:
>
>>
>> On Jun 25, 2009, at 4:38 PM, David Goodwin wrote:
>>
>>> Using the Thumb-2 target we see that ORN ( a | ^b) and BIC (a &  
>>> ^b) have similar patterns, as we would expect:
>>>
>>> defm t2BIC  : T2I_bin_irs<"bic", BinOpFrag<(and node:$LHS, (not  
>>> node:$RHS))>>;
>>> defm t2ORN  : T2I_bin_irs<"orn", BinOpFrag<(or  node:$LHS, (not  
>>> node:$RHS))>>;
>>>
>>> Compiling the following three works as expected:
>>>
>>>    %tmp1 = xor i32 4294967295, %b ;   %tmp2 = or i32 %a, %tmp1   -- 
>>> >  	orn r0, r0, r1
>>>    %tmp1 = xor i32 4294967295, %b ;   %tmp2 = or i32 %tmp1, %a   -- 
>>> >    orn r0, r0, r1
>>>    %tmp = xor i32 %b, 4294967295  ;   %tmp1 = and i32 %a, %tmp   -- 
>>> >    bic r0, r0, r1
>>>
>>> But this doesn't:
>>>
>>>    %tmp = xor i32 %b, 4294967295  ;   %tmp1 = and i32 %tmp, %a   -- 
>>> >    eor r1, r1, #4294967295 ; and r0, r1, r0
>>>
>>> On the surface it seems that the selector is not commuting the AND  
>>> operands. I've attached the complete test files. I can take a look  
>>> but I need a pointer to get started.
>>
>> No, isel is trying to commute the AND. See ARMGenDAGISel.inc (auto- 
>> generated by tablegen):
>>
>>     // Pattern: (and:i32 GPR:i32:$lhs, (xor:i32 t2_so_reg:i32:$rhs,  
>> (imm:i32)<<P:Predicate_immAllOnes>>))
>>     // Emits: (t2BICrs:i32 GPR:i32:$lhs, t2_so_reg:i32:$rhs)
>>     // Pattern complexity = 19  cost = 1  size = 0
>>     {
>>       ..
>>     }
>>
>>
>>     // Pattern: (and:i32 (xor:i32 t2_so_reg:i32:$rhs, (imm:i32) 
>> <<P:Predicate_immAllOnes>>), GPR:i32:$lhs)
>>     // Emits: (t2BICrs:i32 GPR:i32:$lhs, t2_so_reg:i32:$rhs)
>>     // Pattern complexity = 19  cost = 1  size = 0
>>     {
>>      ...
>>      }
>>
>> The second one is the commuted version. Looks like the issue is in  
>> SelectThumb2ShifterOperandReg.
>
> Ugh. It should try to match t2BICrr. But someone tblgen is not  
> generating the commuted version. Very strange. I'm take a look.
>
> Evan
>
>>
>> Evan
>>
>>
>>>
>>> David
>>>
>>> <RM_20_BIC.ll>
>>> <RM_112_ORN.ll>
>>>
>>> _______________________________________________
>>> 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.llvm.org/pipermail/llvm-dev/attachments/20090625/853b42b0/attachment.html>

From artjom.kochtchi at googlemail.com  Fri Jun 26 04:49:31 2009
From: artjom.kochtchi at googlemail.com (Artjom K.)
Date: Fri, 26 Jun 2009 04:49:31 -0700 (PDT)
Subject: [LLVMdev] Inserting nodes into SelectionDAG (X86)
In-Reply-To: <07E3436A-6277-4CD3-B44D-D7F2A9BA2675@apple.com>
References: <24211066.post@talk.nabble.com>
	<07E3436A-6277-4CD3-B44D-D7F2A9BA2675@apple.com>
Message-ID: <24218876.post@talk.nabble.com>


Thank you for your help.

I think I managed to create the instruction I wanted:

  // mov eax, 41
  Chain = DAG.getCopyToReg(Chain, DAG.getRegister(X86::EAX, MVT::i32),
DAG.getConstant(41, MVT::i32), InFlag);
  InFlag = Chain.getValue(1);

I don't understand though what InFlag is for. As I read the code, it even
remains uninitialized when first passed to some node creation method.

Unfortunately I still don't manage to create more sophisticated error free
instructions that actually appear in the assembly generated by llc. For
example after the CopyToReg instruction, I want to increase eax by 1. In X86
'inc eax' would probably be the way to go, which I try to model by ISD 'addc
eax, eax, 1' or something of that sort (it's probably rather 'addc eax, 1').

I've tried all sorts of combinations and ordering of operands I could come
up with, but I seem to be missing the point. This is the most complete
version:

  // inc eax
  Ops.push_back(Chain);
  Ops.push_back(DAG.getRegister(X86::EAX, MVT::i32)); // rather without
target register?
  Ops.push_back(DAG.getRegister(X86::EAX, MVT::i32));
  Ops.push_back(DAG.getConstant(1, MVT::i32));
  Ops.push_back(InFlag);
  Chain = DAG.getNode(ISD::ADDC, DAG.getVTList(MVT::Other, MVT::Flag),
&Ops[0], Ops.size());
  InFlag = Chain.getValue(1);

Usually, llc quits with the error message
llc: SelectionDAG.cpp:4417: llvm::SDValue
llvm::SelectionDAG::UpdateNodeOperands(llvm::SDValue, llvm::SDValue,
llvm::SDValue): Assertion `N->getNumOperands() == 2 && "Update with wrong
number of operands"' failed.
Omiting the target register or switching operand order seems not to change
anything.

I'd really appreciate your help on this.
Artjom
-- 
View this message in context: http://www.nabble.com/Inserting-nodes-into-SelectionDAG-%28X86%29-tp24211066p24218876.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.



From Olaf.Krzikalla at tu-dresden.de  Fri Jun 26 05:32:44 2009
From: Olaf.Krzikalla at tu-dresden.de (Olaf Krzikalla)
Date: Fri, 26 Jun 2009 14:32:44 +0200
Subject: [LLVMdev] Patch for llvm::DepthFirstIterator.h and
	llvm::PostOrderIterator.h
Message-ID: <4A44BFEC.9050301@tu-dresden.de>

Hi @clang and @llvm,

attached you'll find a patch dealing with some iterator issues I already 
mentioned in both lists. Since there was no reaction I cross-post again 
- now IMHO production-ready code.
The patch is considered to get checked-in out of the box. It should not 
affect the behavior of existing and working code. I really need it for 
clang AST processing.

Changes:
1. Both iterators now can deal with sub-nodes==0 - they just skip them 
silently. For AST processing this is badly needed as you sometimes have 
0-nodes in the AST (e.g. in 'for(;;) {}'). Until now both iterators 
crash if they traverse a sub-node==0.
2. In llvm::PostOrderIterator.h I fixed a compile bug which occured if 
used with external storage (which apparently nobody does until now).
3. I changed the behavior of llvm::DepthFirstIterator.h regarding the 
retrieving of the first child. This is now retrieved in exactly that 
moment it's needed. Until now it was retrieved too early, thus you 
actually couldn't change the childs of a just processed node. I can't 
think of an insane working example, which would break due to this change.
4. I added a public skipChilds member function to df_iterator which acts 
similiar to operator++. However it skips all childs of the currently 
processed node and returns *this. You can use it like in
for (i = df_begin(), e = df_end(); i!=e;)
{
  foo() ? i.skipChilds() : ++i;
}


Best
Olaf Krzikalla
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: llvm-iterator.patch
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090626/55728f28/attachment.ksh>

From sabre at nondot.org  Fri Jun 26 11:33:04 2009
From: sabre at nondot.org (Chris Lattner)
Date: Fri, 26 Jun 2009 11:33:04 -0700
Subject: [LLVMdev] LLVM Compiler Infrastructure  and   GDB debugger
In-Reply-To: <000a01c9f689$9250efa0$25362c8d@MOIPC7>
References: <000a01c9f689$9250efa0$25362c8d@MOIPC7>
Message-ID: <A412E438-7724-49FE-B959-27D82FC343EC@nondot.org>

Hi Artem,

GDB only works with native applications.  If you compile your code to  
a native executable with -g, then debug info should work for you.   
However, if you've built your own backend, then you may need to add  
the debug info hooks etc.  If you have further questions, please email  
the llvmdev mailing list instead of me directly, thanks!

-Chris


On Jun 26, 2009, at 11:11 AM, Rudskyy wrote:

> Hallo, Chris Lattner!
> I have found you in LLVM Developers page (http://llvm.org/developers.cgi 
> ).
> First thank you for all of your work with LLVM.
>
> About:
> I work with the LLVM Compiler Infrastructure to implement a backend  
> for specific processor xPEC of chip NetX (http://hilscher.com/netx..html 
> ).
> So C-code already possible compile to the native xPEC assembly code  
> (works perfect! LLWM a big power!).
> Now I need to debug the source C-code, that I compile for xPEC- 
> processor. I have read the article “Source Level Debugging with  
> LLVM” (http://llvm.org/docs/SourceLevelDebugging.html), where were  
> described that is possible to use debugger GDB. Wonderful! I have  
> found much information about GDB (of course http://sourceware.org/ 
> gdb/ ) and it has a debugging of remote programs.
> Problem:
> I don’t understand how must be compiled the C-code with “llvm-gcc”.  
> Wenn I use option “-emit-llvm” [backend needs it] of course with “- 
> g” and “-O0”,  then GDB can’t find a symbol table in bc-file.  Where  
> will place “llvm-gcc” the symbol table for DGB? Perhaps, must GDB  
> knows the architecture of processor? If yes, so where it must be  
> written?   I have many questions and need some help.
> Do you can help me what must I read and search ore recommend  
> somebody to can?
>
>
> Best regards,
> Artem Rudskyy
> http://www..uni-magdeburg.de/ieat/robotslab/
> http://www.uni-magdeburg.de/
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090626/1f7b1eb1/attachment.html>

From eli.friedman at gmail.com  Fri Jun 26 15:23:41 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Fri, 26 Jun 2009 15:23:41 -0700
Subject: [LLVMdev] [cfe-dev] LLVM frontend supporting arbitrary
	bit-width integral datatypes
In-Reply-To: <4A4386A7.1040309@free.fr>
References: <op.uuwe38tn0lgsd9@localhost.localdomain> <4A2834A8.2080402@tut.fi>
	<op.uv04gua50lgsd9@localhost.localdomain> <4A4228B8.8040005@free.fr>
	<4A438565.7040307@getdesigned.at> <4A4386A7.1040309@free.fr>
Message-ID: <f5aa3e9b0906261523k61a1df6cue51adf87a2df7397@mail.gmail.com>

On Thu, Jun 25, 2009 at 7:16 AM, Duncan Sands<baldrick at free.fr> wrote:
> Hi Sebastian,
>
>> You're producing a signed overflow, which is simply undefined behavior.
>> Unsigned overflow is well-defined, even for bitfields, but signed is not.
>
> that's true, here's an unsigned version (outputs 5 + 5 = 2):
>
> #include <stdio.h>
>
> struct i3 { unsigned i:3; };
>
> int main(void) {
>   struct i3 A, B, C;
>
>   A.i = 5;
>   B.i = 5;
>   C.i = A.i + B.i;
>   printf("%d + %d = %d\n", A.i, B.i, C.i);
>   return 0;
> }

Note that you're actually doing signed arithmetic here; it just
doesn't happen to matter because "int" is much larger than the
bitfield.

-Eli



From azaks at sta.samsung.com  Fri Jun 26 15:11:30 2009
From: azaks at sta.samsung.com (Anna Zaks)
Date: Fri, 26 Jun 2009 17:11:30 -0500
Subject: [LLVMdev] Using LLVM on an embedded device
References: <06D0EA1E017D5048884831C10A60EA4C071E0A05@mx2.telecom.sna.samsung.com>
	<ADCE5AA1DF84024C88B9B8A29D9553C6044976FB@mx2.telecom.sna.samsung.com>
Message-ID: <ADCE5AA1DF84024C88B9B8A29D9553C6044976FC@mx2.telecom.sna.samsung.com>

Hi Evan,

Sorry for the delayed reply. We've compiled llvm on Linux with only the x86 target, which produced an lli executable that's about 5.5MB. The LLVMX86CodeGen.o alone is 1.7MB. We've configured with 

--disable-assertions --enable-optimized --enable-targets=x86 --disable-debug-runtime --enable-bindings=none --disable-ltdl-install --disable-shared --enable-static

Are there any tips on making them even smaller? It seems that the ARM backend would be smaller but I am not sure if we could get it under 2MB. Also I guess, the interpreter could be removed, but it is quite small (145KB). 

Thank you,
Anna.
 

> Hi,
>
> I am researching a possibility of running LLVM components (such as  
> JIT) on an embedded device, where the memory footprint and RAM usage  
> are the main concerns. So I was wondering if anyone could share  
> their experience with running LLVM on an embedded device. What is  
> the approximate code footprint that we are looking at? For example,  
> on an x86 with a minimum set of optimizations and with only the x86  
> backend, it seems difficult to get the LLVM JIT occupy less than  
> 5MB. Is there any performance and memory usage data available?

That seems too high. I would think it's more in the 2MB range. How did  
you come about that figure? x86 instruction selector itself is quite  
large due to the complex selection patterns. I would expect ARM's  
footprint to be smaller.

There are ways to reduce memory foot print further. But it will  
require someone to drive the effort. One of the (very rough) idea is  
to switch to a table driven instruction selector.

Evan

>
> Thank you!
> Anna.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090626/10cf7d68/attachment.html>

From david_goodwin at apple.com  Fri Jun 26 16:25:14 2009
From: david_goodwin at apple.com (David Goodwin)
Date: Fri, 26 Jun 2009 16:25:14 -0700
Subject: [LLVMdev] "icmp eq", "icmp ne" not commuting operands on ARM
Message-ID: <41E09FA9-5D83-4B21-916F-9F60FD1B2F7D@apple.com>

NE and EQ comparisons should be able to commute their operands. But,  
for ARM at least, this does not seem to be happening. The first  
sequence below generates CMN (compare negated) but the second does not  
(complete test attached). These seem to map to ARMcmpNZ. Where would I  
look to see if that is marked commutative?

     %nb = sub i32 0, %b
     %tmp = icmp ne i32 %a, %nb

     %nb = sub i32 0, %b
     %tmp = icmp ne i32 %nb, %a

David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: thumb2-cmn.ll
Type: application/octet-stream
Size: 526 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090626/783a00c4/attachment.obj>
-------------- next part --------------


From evan.cheng at apple.com  Fri Jun 26 17:16:35 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Fri, 26 Jun 2009 17:16:35 -0700
Subject: [LLVMdev] "icmp eq", "icmp ne" not commuting operands on ARM
In-Reply-To: <41E09FA9-5D83-4B21-916F-9F60FD1B2F7D@apple.com>
References: <41E09FA9-5D83-4B21-916F-9F60FD1B2F7D@apple.com>
Message-ID: <DA65845A-56C2-4D1A-8522-906990CFF309@apple.com>

David and I talked off line. He's going to fix it.

Evan

On Jun 26, 2009, at 4:25 PM, David Goodwin wrote:

> NE and EQ comparisons should be able to commute their operands. But,  
> for ARM at least, this does not seem to be happening. The first  
> sequence below generates CMN (compare negated) but the second does  
> not (complete test attached). These seem to map to ARMcmpNZ. Where  
> would I look to see if that is marked commutative?
>
>    %nb = sub i32 0, %b
>    %tmp = icmp ne i32 %a, %nb
>
>    %nb = sub i32 0, %b
>    %tmp = icmp ne i32 %nb, %a
>
> David
>
> <thumb2-cmn.ll>
> _______________________________________________
> 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  Sat Jun 27 16:21:18 2009
From: gohman at apple.com (Dan Gohman)
Date: Sat, 27 Jun 2009 16:21:18 -0700
Subject: [LLVMdev] Inserting nodes into SelectionDAG (X86)
In-Reply-To: <24218876.post@talk.nabble.com>
References: <24211066.post@talk.nabble.com>
	<07E3436A-6277-4CD3-B44D-D7F2A9BA2675@apple.com>
	<24218876.post@talk.nabble.com>
Message-ID: <5B6FAE89-05DC-44D9-B932-7B8A1927DCE3@apple.com>


On Jun 26, 2009, at 4:49 AM, Artjom K. wrote:

>
> Thank you for your help.
>
> I think I managed to create the instruction I wanted:
>
>  // mov eax, 41
>  Chain = DAG.getCopyToReg(Chain, DAG.getRegister(X86::EAX, MVT::i32),
> DAG.getConstant(41, MVT::i32), InFlag);
>  InFlag = Chain.getValue(1);
>
> I don't understand though what InFlag is for. As I read the code, it  
> even
> remains uninitialized when first passed to some node creation method.

Flag operands in SelectionDAG are special.  SelectionDAG currently
requires Flag operands for copies to and from physical registers,
though not for virtual registers.

>
> Unfortunately I still don't manage to create more sophisticated  
> error free
> instructions that actually appear in the assembly generated by llc.  
> For
> example after the CopyToReg instruction, I want to increase eax by  
> 1. In X86
> 'inc eax' would probably be the way to go, which I try to model by  
> ISD 'addc
> eax, eax, 1' or something of that sort (it's probably rather 'addc  
> eax, 1').

ADDC is add-with-carry. If you just want to add 1 to EAX and don't care
about the carry result, ADD is easier.  The result type of ADD is just
MVT::i32 (assuming you're working with i32 operands).

Dan



From gohman at apple.com  Sat Jun 27 16:41:09 2009
From: gohman at apple.com (Dan Gohman)
Date: Sat, 27 Jun 2009 16:41:09 -0700
Subject: [LLVMdev] Patch for llvm::DepthFirstIterator.h and
	llvm::PostOrderIterator.h
In-Reply-To: <4A44BFEC.9050301@tu-dresden.de>
References: <4A44BFEC.9050301@tu-dresden.de>
Message-ID: <6A4C1440-4054-4EE1-A21E-CF6A55AEE8A1@apple.com>

Hi Olaf,

This patch looks good to me.  I just have a few minor comments:

 > +  inline df_iterator() { CurrentTopNode = 0; /* End is when stack  
is empty */ }

Should the comment here be updated to say that the End
is reached when the stack is empty and when CurrentTopNode
is null?

 > +  inline void toNext()
 > +  {

LLVM style puts the open brace on the same line as the function name.

 > +  inline _Self& skipChilds() {  // skips all childs of the current  
node and traverses to next node

The plural of "child" is "children"; please rename this function
accordingly.  Also, please format this line and a few others so
that they don't exceed 80 columns.

Thanks,

Dan

On Jun 26, 2009, at 5:32 AM, Olaf Krzikalla wrote:

> Hi @clang and @llvm,
>
> attached you'll find a patch dealing with some iterator issues I  
> already mentioned in both lists. Since there was no reaction I cross- 
> post again - now IMHO production-ready code.
> The patch is considered to get checked-in out of the box. It should  
> not affect the behavior of existing and working code. I really need  
> it for clang AST processing.
>
> Changes:
> 1. Both iterators now can deal with sub-nodes==0 - they just skip  
> them silently. For AST processing this is badly needed as you  
> sometimes have 0-nodes in the AST (e.g. in 'for(;;) {}'). Until now  
> both iterators crash if they traverse a sub-node==0.
> 2. In llvm::PostOrderIterator.h I fixed a compile bug which occured  
> if used with external storage (which apparently nobody does until  
> now).
> 3. I changed the behavior of llvm::DepthFirstIterator.h regarding  
> the retrieving of the first child. This is now retrieved in exactly  
> that moment it's needed. Until now it was retrieved too early, thus  
> you actually couldn't change the childs of a just processed node. I  
> can't think of an insane working example, which would break due to  
> this change.
> 4. I added a public skipChilds member function to df_iterator which  
> acts similiar to operator++. However it skips all childs of the  
> currently processed node and returns *this. You can use it like in
> for (i = df_begin(), e = df_end(); i!=e;)
> {
> foo() ? i.skipChilds() : ++i;
> }
>
>
> Best
> Olaf Krzikalla
> <llvm-iterator.patch>_______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



From hc2428 at columbia.edu  Sat Jun 27 21:48:19 2009
From: hc2428 at columbia.edu (hc2428 at columbia.edu)
Date: Sun, 28 Jun 2009 00:48:19 -0400
Subject: [LLVMdev] Error when running llc to compile .bc to .s
In-Reply-To: <6A4C1440-4054-4EE1-A21E-CF6A55AEE8A1@apple.com>
References: <4A44BFEC.9050301@tu-dresden.de>
	<6A4C1440-4054-4EE1-A21E-CF6A55AEE8A1@apple.com>
Message-ID: <20090628004819.rduisl3d4sgscggk@cubmail.cc.columbia.edu>

Dear staff,

     I downloaded an llvm version from the svn trunk at June 12,  
because the released 2.5 version can not support "gcc -g -Ox", and  
x=1,2,3. I use the version in svn to compile an httpd.bc file  
succefully with dbgstoppoint() functions. However, when I use llc to  
compile the bc file to .s file (llc -f -o httpd.s httpd.bc), I met  
this error (the httpd.bc file will be attached at the next email):

llc:  
/home/heming/defens/llvm-2.5/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:1235: void  
llvm::DwarfDebug::ConstructCompileUnit(llvm::GlobalVariable*):  
Assertion `!MainCU && "Multiple main compile units are found!"' failed.
0   llc             0x00000000011c0f6c
1   llc             0x00000000011c148a
2   libpthread.so.0 0x00007fa91db297d0
3   libc.so.6       0x00007fa91cc3a095 gsignal + 53
4   libc.so.6       0x00007fa91cc3baf0 abort + 272
5   libc.so.6       0x00007fa91cc332df __assert_fail + 239
6   llc             0x0000000000ebfdad
7   llc             0x0000000000ebffa6
8   llc             0x0000000000ec2f7b
9   llc             0x0000000000eb95e0  
llvm::DwarfWriter::BeginModule(llvm::Module*,  
llvm::MachineModuleInfo*, llvm::raw_ostream&, llvm::AsmPrinter*,  
llvm::TargetAsmInfo const*) + 166
10  llc             0x0000000000b9b513
11  llc             0x0000000001142c73  
llvm::FPPassManager::doInitialization(llvm::Module&) + 65
12  llc             0x0000000001142d96  
llvm::FunctionPassManagerImpl::doInitialization(llvm::Module&) + 58
13  llc             0x0000000001142e01  
llvm::FunctionPassManager::doInitialization() + 41
14  llc             0x000000000084b43d main + 2481
15  libc.so.6       0x00007fa91cc261c4 __libc_start_main + 244
16  llc             0x0000000000849849
Stack dump:
0.      Program arguments: llc -f -o httpd.s httpd.bc
Aborted





From hc2428 at columbia.edu  Sat Jun 27 21:52:17 2009
From: hc2428 at columbia.edu (hc2428 at columbia.edu)
Date: Sun, 28 Jun 2009 00:52:17 -0400
Subject: [LLVMdev] Error when running llc to compile .bc to .s
In-Reply-To: <20090628004819.rduisl3d4sgscggk@cubmail.cc.columbia.edu>
References: <4A44BFEC.9050301@tu-dresden.de>
	<6A4C1440-4054-4EE1-A21E-CF6A55AEE8A1@apple.com>
	<20090628004819.rduisl3d4sgscggk@cubmail.cc.columbia.edu>
Message-ID: <20090628005217.rmq1vy57ok8w4000@cubmail.cc.columbia.edu>

Quoting hc2428 at columbia.edu:

The httpd.bc file is compiled with "-g -O0" option (I pass "-g -O0" to  
CFLAGS). If I eliminate the -g option (just pass "-O0" to CFLAGS), I  
got the httpd.bc file with a size of 1.1M bytes, and the llc can  
compile the httpd.bc file to httpd.s file. If I added the -g option, I  
got the httpd.bc file with a size of 3.8M bytes, and I got the error  
as below when using llc.

> Dear staff,
>
>      I downloaded an llvm version from the svn trunk at June 12,
> because the released 2.5 version can not support "gcc -g -Ox", and
> x=1,2,3. I use the version in svn to compile an httpd.bc file
> succefully with dbgstoppoint() functions. However, when I use llc to
> compile the bc file to .s file (llc -f -o httpd.s httpd.bc), I met
> this error (the httpd.bc file will be attached at the next email):
>
> llc:
> /home/heming/defens/llvm-2.5/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:1235: void
> llvm::DwarfDebug::ConstructCompileUnit(llvm::GlobalVariable*):
> Assertion `!MainCU && "Multiple main compile units are found!"' failed.
> 0   llc             0x00000000011c0f6c
> 1   llc             0x00000000011c148a
> 2   libpthread.so.0 0x00007fa91db297d0
> 3   libc.so.6       0x00007fa91cc3a095 gsignal + 53
> 4   libc.so.6       0x00007fa91cc3baf0 abort + 272
> 5   libc.so.6       0x00007fa91cc332df __assert_fail + 239
> 6   llc             0x0000000000ebfdad
> 7   llc             0x0000000000ebffa6
> 8   llc             0x0000000000ec2f7b
> 9   llc             0x0000000000eb95e0
> llvm::DwarfWriter::BeginModule(llvm::Module*,
> llvm::MachineModuleInfo*, llvm::raw_ostream&, llvm::AsmPrinter*,
> llvm::TargetAsmInfo const*) + 166
> 10  llc             0x0000000000b9b513
> 11  llc             0x0000000001142c73
> llvm::FPPassManager::doInitialization(llvm::Module&) + 65
> 12  llc             0x0000000001142d96
> llvm::FunctionPassManagerImpl::doInitialization(llvm::Module&) + 58
> 13  llc             0x0000000001142e01
> llvm::FunctionPassManager::doInitialization() + 41
> 14  llc             0x000000000084b43d main + 2481
> 15  libc.so.6       0x00007fa91cc261c4 __libc_start_main + 244
> 16  llc             0x0000000000849849
> Stack dump:
> 0.      Program arguments: llc -f -o httpd.s httpd.bc
> Aborted
>
>
>
> _______________________________________________
> 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  Sat Jun 27 21:56:02 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Sat, 27 Jun 2009 21:56:02 -0700
Subject: [LLVMdev] Error when running llc to compile .bc to .s
In-Reply-To: <20090628004819.rduisl3d4sgscggk@cubmail.cc.columbia.edu>
References: <4A44BFEC.9050301@tu-dresden.de>	<6A4C1440-4054-4EE1-A21E-CF6A55AEE8A1@apple.com>
	<20090628004819.rduisl3d4sgscggk@cubmail.cc.columbia.edu>
Message-ID: <4A46F7E2.3070107@mxc.ca>

hc2428 at columbia.edu wrote:
> Dear staff,
> 
>      I downloaded an llvm version from the svn trunk at June 12,  
> because the released 2.5 version can not support "gcc -g -Ox", and  
> x=1,2,3. I use the version in svn to compile an httpd.bc file  
> succefully with dbgstoppoint() functions. However, when I use llc to  
> compile the bc file to .s file (llc -f -o httpd.s httpd.bc), I met  
> this error (the httpd.bc file will be attached at the next email):
> 
> llc:  
> /home/heming/defens/llvm-2.5/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:1235: void  
> llvm::DwarfDebug::ConstructCompileUnit(llvm::GlobalVariable*):  
> Assertion `!MainCU && "Multiple main compile units are found!"' failed.

http://llvm.org/PR3494 . I'm guessing you did what I did; took a bunch 
of .bc files compiled with debug info and merged them with llvm-link or 
llvm-ld or some other sort of merge, then tried to compile the result. 
This is known broken.

Nick


> 0   llc             0x00000000011c0f6c
> 1   llc             0x00000000011c148a
> 2   libpthread.so.0 0x00007fa91db297d0
> 3   libc.so.6       0x00007fa91cc3a095 gsignal + 53
> 4   libc.so.6       0x00007fa91cc3baf0 abort + 272
> 5   libc.so.6       0x00007fa91cc332df __assert_fail + 239
> 6   llc             0x0000000000ebfdad
> 7   llc             0x0000000000ebffa6
> 8   llc             0x0000000000ec2f7b
> 9   llc             0x0000000000eb95e0  
> llvm::DwarfWriter::BeginModule(llvm::Module*,  
> llvm::MachineModuleInfo*, llvm::raw_ostream&, llvm::AsmPrinter*,  
> llvm::TargetAsmInfo const*) + 166
> 10  llc             0x0000000000b9b513
> 11  llc             0x0000000001142c73  
> llvm::FPPassManager::doInitialization(llvm::Module&) + 65
> 12  llc             0x0000000001142d96  
> llvm::FunctionPassManagerImpl::doInitialization(llvm::Module&) + 58
> 13  llc             0x0000000001142e01  
> llvm::FunctionPassManager::doInitialization() + 41
> 14  llc             0x000000000084b43d main + 2481
> 15  libc.so.6       0x00007fa91cc261c4 __libc_start_main + 244
> 16  llc             0x0000000000849849
> Stack dump:
> 0.      Program arguments: llc -f -o httpd.s httpd.bc
> Aborted
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 



From carter_cheng at yahoo.com  Sun Jun 28 01:05:16 2009
From: carter_cheng at yahoo.com (Carter Cheng)
Date: Sun, 28 Jun 2009 01:05:16 -0700 (PDT)
Subject: [LLVMdev] Several basic questions about Builder
Message-ID: <489088.90520.qm@web50102.mail.re2.yahoo.com>


I have been toying around with the LLVM tutorial code and I am trying to deduce what I can from it as a basis for a compiler frontend for a simple language of my own devising (once I understand what I am doing I will probably attempt mapping a more complex language target). I am having some difficulties however understanding how certain things work and I was hoping perhaps someone could help me out-

1) Using the Builder interface how does one create the equivalent of stack frames and access variables in the current stack frame or perhaps in the static enclosing scope (assuming functions can be nested)?

2) Is it possible to deallocate functions from a module and recycle the memory used without restarting the JIT? I am trying to build a server type application where objects/classes maybe be deallocated and thus the associated functions will no longer be used.

3) How does one sequence instructions using Builder similar to a semi-colon in a language like C?

Thanks in advance,

Carter.


      


From eli.friedman at gmail.com  Sun Jun 28 02:39:45 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Sun, 28 Jun 2009 02:39:45 -0700
Subject: [LLVMdev] Several basic questions about Builder
In-Reply-To: <489088.90520.qm@web50102.mail.re2.yahoo.com>
References: <489088.90520.qm@web50102.mail.re2.yahoo.com>
Message-ID: <f5aa3e9b0906280239g1fedaca0w86d523d948de9cf9@mail.gmail.com>

On Sun, Jun 28, 2009 at 1:05 AM, Carter Cheng<carter_cheng at yahoo.com> wrote:
> 1) Using the Builder interface how does one create the equivalent of stack frames and access variables in the current stack frame or perhaps in the static enclosing scope (assuming functions can be nested)?

To create stack variables, you can use the alloca instruction; see
http://llvm.org/docs/tutorial/LangImpl7.html#memory .

LLVM doesn't directly support nested functions; you'll have to lower
them yourself.  For example, try something like the following in the
LLVM demo page (http://llvm.org/demo/index.cgi) with optimization off:
int main(int argc, char **argv) {
  void a(int x) { if (x == 10) return; a(x+1); argc += x; }
  a(0);
  return argc;
}

> 2) Is it possible to deallocate functions from a module and recycle the memory used without restarting the JIT? I am trying to build a server type application where objects/classes maybe be deallocated and thus the associated functions will no longer be used.

That should be possible; I'm not sure of the details, though.

> 3) How does one sequence instructions using Builder similar to a semi-colon in a language like C?

Instructions are ordered within a basic block, and they are guaranteed
to be executed in that order.  If you just build the instructions in
the same order that the statements occur in the code, it should work
without any special tweaking.

-Eli



From tema13tema at yahoo.de  Sun Jun 28 04:15:22 2009
From: tema13tema at yahoo.de (Rudskyy)
Date: Sun, 28 Jun 2009 13:15:22 +0200
Subject: [LLVMdev] LLVM Compiler Infrastructure  and   GDB debugger
Message-ID: <004201c9f7e1$bb1222c0$25362c8d@MOIPC7>

Hallo, LLVMdev! 

I have found you in LLVM Developers page (http://llvm.org/developers.cgi). 

First thank you for all of your work with LLVM.

 

About:

I work with the LLVM Compiler Infrastructure to implement a backend for
specific processor xPEC of chip NetX (http://hilscher.com/netx.html).

So C-code already possible compile to the native xPEC assembly code (works
perfect! LLWM a big power!). 

Now I need to debug the source C-code, that I compile for xPEC-processor. I
have read the article "Source Level Debugging with LLVM"
(http://llvm.org/docs/SourceLevelDebugging.html), where were described that
is possible to use debugger GDB. Wonderful! I have found much information
about GDB (of course http://sourceware.org/gdb/ ) and it has a debugging of
remote programs. 

Problem:

I don't understand how must be compiled the C-code with "llvm-gcc". Wenn I
use option "-emit-llvm" [backend needs it] of course with "-g" and "-O0",
then GDB can't find a symbol table in bc-file.  Where will place "llvm-gcc"
the symbol table for DGB? Perhaps, must GDB knows the architecture of
processor? If yes, so where it must be written?   I have many questions and
need some help. 

Do you can help me what must I read and search ore recommend somebody to
can? 

 

 

Best regards,

Artem Rudskyy

http://www.uni-magdeburg.de/ieat/robotslab/

http://www.uni-magdeburg.de/

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090628/9b93d43d/attachment.html>

From hc2428 at columbia.edu  Sat Jun 27 21:53:11 2009
From: hc2428 at columbia.edu (hc2428 at columbia.edu)
Date: Sun, 28 Jun 2009 00:53:11 -0400
Subject: [LLVMdev] Error when running llc to compile .bc to .s
In-Reply-To: <20090628004819.rduisl3d4sgscggk@cubmail.cc.columbia.edu>
References: <4A44BFEC.9050301@tu-dresden.de>
	<6A4C1440-4054-4EE1-A21E-CF6A55AEE8A1@apple.com>
	<20090628004819.rduisl3d4sgscggk@cubmail.cc.columbia.edu>
Message-ID: <20090628005311.t7c40dymg4oo0kgg@cubmail.cc.columbia.edu>

Quoting hc2428 at columbia.edu:

Here is the httpd.bc file I got with "-g -O0" option.

> Dear staff,
>
>      I downloaded an llvm version from the svn trunk at June 12,
> because the released 2.5 version can not support "gcc -g -Ox", and
> x=1,2,3. I use the version in svn to compile an httpd.bc file
> succefully with dbgstoppoint() functions. However, when I use llc to
> compile the bc file to .s file (llc -f -o httpd.s httpd.bc), I met
> this error (the httpd.bc file will be attached at the next email):
>
> llc:
> /home/heming/defens/llvm-2.5/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:1235: void
> llvm::DwarfDebug::ConstructCompileUnit(llvm::GlobalVariable*):
> Assertion `!MainCU && "Multiple main compile units are found!"' failed.
> 0   llc             0x00000000011c0f6c
> 1   llc             0x00000000011c148a
> 2   libpthread.so.0 0x00007fa91db297d0
> 3   libc.so.6       0x00007fa91cc3a095 gsignal + 53
> 4   libc.so.6       0x00007fa91cc3baf0 abort + 272
> 5   libc.so.6       0x00007fa91cc332df __assert_fail + 239
> 6   llc             0x0000000000ebfdad
> 7   llc             0x0000000000ebffa6
> 8   llc             0x0000000000ec2f7b
> 9   llc             0x0000000000eb95e0
> llvm::DwarfWriter::BeginModule(llvm::Module*,
> llvm::MachineModuleInfo*, llvm::raw_ostream&, llvm::AsmPrinter*,
> llvm::TargetAsmInfo const*) + 166
> 10  llc             0x0000000000b9b513
> 11  llc             0x0000000001142c73
> llvm::FPPassManager::doInitialization(llvm::Module&) + 65
> 12  llc             0x0000000001142d96
> llvm::FunctionPassManagerImpl::doInitialization(llvm::Module&) + 58
> 13  llc             0x0000000001142e01
> llvm::FunctionPassManager::doInitialization() + 41
> 14  llc             0x000000000084b43d main + 2481
> 15  libc.so.6       0x00007fa91cc261c4 __libc_start_main + 244
> 16  llc             0x0000000000849849
> Stack dump:
> 0.      Program arguments: llc -f -o httpd.s httpd.bc
> Aborted
>
>
>
> _______________________________________________
> 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: httpd.bc.tar.gz
Type: application/x-gzip-compressed
Size: 1892467 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090628/9772cde1/attachment.bin>

From luoyonggang at gmail.com  Sun Jun 28 04:47:01 2009
From: luoyonggang at gmail.com (=?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?=)
Date: Sun, 28 Jun 2009 19:47:01 +0800
Subject: [LLVMdev] The document fault in llvm doc. And a comiling error
Message-ID: <806065d90906280447o70c9bcd2qd18468fcb63d8f7d@mail.gmail.com>

most html document need to add
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
int <head> section of html
such as
<head>
 <meta http-equiv="content-type" content="text/html; charset=UTF-8">
other staff
</head>
this is the correct style.

.\llvm\docs\SourceLevelDebugging.html
Chris Lattner sabre at nondot.org
Jim Laskey jlaskey at mac.com
 Philosophy behind LLVM debugging information
while don't change the link
 http://www.eagercon.com/dwarf/dwarf3std.htm
to
 http://www.dwarfstd.org/
and i found the link in http://www.eagercon.com/dwarf/dwarf3std.htmis not
accessible.

.\llvm\docs\ExtendingLLVM.html
Written by Misha Brukman, Brad Jones, Nate Begeman, and Chris Lattner
In section
Adding a new instruction
 4.llvm/lib/AsmParser/Lexer.l: add a new token to parse your instruction
from assembly text file
5.llvm/lib/AsmParser/llvmAsmParser.y: add the grammar on how your
instruction can be read and what it will construct as a result
 Adding a new type
3.llvm/lib/AsmReader/Lexer.l: add ability to parse in the type from text
assembly
 4.llvm/lib/AsmReader/llvmAsmParser.y: add a token for that type

also, this file need to add a meta data that set charset to utf-8
 such as <meta http-equiv="content-type" content="text/html; charset=UTF-8">
and also many other files:.


.\llvm\docs\CompilerWriterInfo.html
1.Hardware
 Other x86-specific information
need change the url of
•Calling conventions for different C++ compilers and operating systems
 the new one is

3.Miscellaneous resources
http://www.agner.org/optimize/#manuals
 I think need to add
The DWARF Debugging Standard
http://www.dwarfstd.org/
 Portable Executable
http://en.wikipedia.org/wiki/Portable_Executable
 Microsoft Portable Executable and Common Object File Format Specification
http://www.microsoft.com/whdc/system/platform/firmware/PECOFFdwn.mspx
 An In-Depth Look into the Win32 Portable Executable File Format
http://msdn.microsoft.com/en-us/magazine/cc301805.aspx
 Object file converter
http://www.agner.org/optimize/#objconv
 Damn good staff
 On windows 7 platfrom
once I compiling with gcc or msvc, the tablgen can't running fine:
Assertion failed: errorcode == 0, file
d:/svn/llvm/lib/System/Win32/ThreadLocal.
inc, line 46

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
make[2]: *** [include/llvm/Intrinsics.gen.tmp] Error 3
make[1]: *** [include/llvm/CMakeFiles/intrinsics_gen.dir/all] Error 2
make: *** [all] Error 2

-- 
        此致
礼
罗勇刚
Yonggang Luo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090628/117fcea2/attachment.html>

From eli.friedman at gmail.com  Sun Jun 28 11:31:32 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Sun, 28 Jun 2009 11:31:32 -0700
Subject: [LLVMdev] LLVM Compiler Infrastructure and GDB debugger
In-Reply-To: <004201c9f7e1$bb1222c0$25362c8d@MOIPC7>
References: <004201c9f7e1$bb1222c0$25362c8d@MOIPC7>
Message-ID: <f5aa3e9b0906281131j2510143fh45d1853235f43d3a@mail.gmail.com>

On Sun, Jun 28, 2009 at 4:15 AM, Rudskyy<tema13tema at yahoo.de> wrote:
> Where will place “llvm-gcc” the symbol table for GDB?

The relevant information is all available in the .bc file, but not in
any directly usable format; the LLVM code generator (in lib/CodeGen)
writes the appropriate assembly so that the assembler writes the
appropriate symbol table and debug info in the assembled .o file.

Symbols fall out naturally from having a native .o file, since the
linker needs to be able to read them.  Detailed source-level debug
info gets written out by include/CodeGen/DwarfWriter.h and related
code; if you're not using a LLVM-style backend, you'll need to call
into it yourself.  You should be able to do some limited amount of
debugging without debug information, though, so I'd suggest
concentrating on getting everything else working first.

> Perhaps, must GDB knows the architecture of
> processor? If yes, so where it must be written?

Yes, gdb must be aware of the target; if it's a target gdb knows
about, it should be enough to pass an appropriate "--target" to
configure, but otherwise you'll have to write some code.  See
http://sourceware.org/gdb/download/onlinedocs/gdbint_9.html#SEC83 and
http://sourceware.org/gdb/download/onlinedocs/gdbint_15.html, I guess,
but I don't know very much about it.

-Eli



From sanjiv.gupta at microchip.com  Sun Jun 28 11:37:20 2009
From: sanjiv.gupta at microchip.com (Sanjiv Gupta)
Date: Mon, 29 Jun 2009 00:07:20 +0530
Subject: [LLVMdev] llvmc for PIC16
In-Reply-To: <3cb898890906231349l47a91d6m57c48fa8fc9617b@mail.gmail.com>
References: <4A2633E9.4070207@microchip.com> <4A28C062.9060307@microchip.com>	
	<loom.20090607T070933-452@post.gmane.org>	
	<4A35EA76.7090602@microchip.com>	
	<3cb898890906150348l2e0d4095seb54de38f95e69f9@mail.gmail.com>	
	<4A3656A3.1050403@microchip.com>	
	<3cb898890906150730k534167dfxf59677e966477220@mail.gmail.com>	
	<4A39F1D7.4060101@microchip.com>	
	<3cb898890906180430k5cb0d57fh7c66d10a45c50db0@mail.gmail.com>	
	<F536B7C316F9474E9F7091239725AC9A4E90DA@CHN-CL-MAIL01.mchp-main.com>
	<3cb898890906231349l47a91d6m57c48fa8fc9617b@mail.gmail.com>
Message-ID: <4A47B860.6020208@microchip.com>

Mikhail Glushenkov wrote:
> Hi Sanjiv,
>
> 2009/6/23 <Sanjiv.Gupta at microchip.com>
>   
>>> BTW, Chris's Makefile changes broke llvmc yesterday (r75379). I'm
>>> working on a fix.
>>>       
>> Hi Mikhail,
>> Did you get a chance to fix this. I still get errors while building examples.
>>
>>     
>
> This issue should be fixed now (r74001+).
>
>   
Yes. It works now.
I have a few more things to ask.
In a command line such as below:

clang-cc -triple=pic16- -emit-llvm-bc hello.c -o /tmp/llvm_YdmvZG/hello.bc


who is suppose to create TmpDir  /tmp/llvm_YdmvZG/  ?
I see neither the driver nor clang-cc creates it.

How to change TmpDir? For example I may want to create a Debug or 
Release dir under the current dir to create binaries, then how to say 
that ./Debug or ./Release should be used by the driver as TmpDir ?

- Sanjiv


From the.dead.shall.rise at gmail.com  Sun Jun 28 12:09:15 2009
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Sun, 28 Jun 2009 21:09:15 +0200
Subject: [LLVMdev] llvmc for PIC16
In-Reply-To: <4A47B860.6020208@microchip.com>
References: <4A2633E9.4070207@microchip.com> <4A35EA76.7090602@microchip.com>
	<3cb898890906150348l2e0d4095seb54de38f95e69f9@mail.gmail.com>
	<4A3656A3.1050403@microchip.com>
	<3cb898890906150730k534167dfxf59677e966477220@mail.gmail.com>
	<4A39F1D7.4060101@microchip.com>
	<3cb898890906180430k5cb0d57fh7c66d10a45c50db0@mail.gmail.com>
	<F536B7C316F9474E9F7091239725AC9A4E90DA@CHN-CL-MAIL01.mchp-main.com>
	<3cb898890906231349l47a91d6m57c48fa8fc9617b@mail.gmail.com>
	<4A47B860.6020208@microchip.com>
Message-ID: <3cb898890906281209k47ced2d0kc99d8425a4c034b9@mail.gmail.com>

Hi Sanjiv,

2009/6/28 Sanjiv Gupta <sanjiv.gupta at microchip.com>:
> I have a few more things to ask.
> In a command line such as below:
>
> clang-cc -triple=pic16- -emit-llvm-bc hello.c -o /tmp/llvm_YdmvZG/hello.bc
>
>
> who is suppose to create TmpDir  /tmp/llvm_YdmvZG/  ?
> I see neither the driver nor clang-cc creates it.

The temporary directory is created by the driver automatically, the
same as with gcc (see include/llvm/CompilerDriver/Main.inc, if you're
interested in details).

> How to change TmpDir? For example I may want to create a Debug or Release
> dir under the current dir to create binaries, then how to say that ./Debug
> or ./Release should be used by the driver as TmpDir ?

I think that this should be the responsibility of the build system.
Example (Makefile syntax):

$(BuildMode)/%.o : %.c
    llvmc -c $SOURCE -o $(BuildMode)/$TARGET

$(BuildMode)/$(ProgramName) : $(ObjectFiles)
    llvmc $(ObjectFiles) -o $(BuildMode)/$(ProgramName)

This is basically what LLVM's build system does.

There is also the -save-temps option which was recently modified to
behave like GCC 4.5. You can now do:

llvmc -save-temps=obj -o MyTempDir MyFile.c

This will produce an executable named a.out in the current directory
and save all temporary files to MyTempDir.


-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments



From davidterei at gmail.com  Sun Jun 28 23:00:18 2009
From: davidterei at gmail.com (David Terei)
Date: Mon, 29 Jun 2009 16:00:18 +1000
Subject: [LLVMdev] Pinning registers in LLVM
Message-ID: <F8C491D7-1C02-4C61-B690-1D62346EA9F6@gmail.com>

Hi all,

I'm working on using LLVM as a back-end for an existing compiler (GHC  
Haskell compiler) and one of the problems I'm having is pinning a  
global variable to a actual machine register. I've seen mixed  
terminology for this feature/idea, so what I mean by this is that I  
want to be able to put a global variable into a specified hardware  
register. This declaration should thus reserve that machine register  
for exclusive use by this global variable. This is used in GHC since  
it defines an abstract machine as part of its execution model, with  
this abstract machine consisting of several virtual registers. Due to  
the frequency the virtual registers are accessed it is best for  
performance that they be permanently assigned to a physical machine  
register.

GCC supports an extension to enable this feature, which is described  
here:

http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Global-Reg-Vars.html

A very simple example C program using this feature:

--------------------------
#include <stdio.h>

register int R1 __asm__ ("esi");

int main(void)
{
	R1 = 3;
	printf("register: %d\n", R1);
	R1 *= 2;
	printf("register: %d\n", R1);
	return 0;
}
--------------------------

llvm-gcc doesn't compile this program correctly, although according to  
the llvm-gcc release notes this extension was first supported by llvm- 
gcc in 1.9.

gcc output:

     register: 3
     register: 6

llvm-gcc output:

     register: 3
     register: 16330

So just hoping this can be done with LLVM and if so, then how.

Cheers,
David Terei


From carter_cheng at yahoo.com  Mon Jun 29 01:10:25 2009
From: carter_cheng at yahoo.com (Carter Cheng)
Date: Mon, 29 Jun 2009 01:10:25 -0700 (PDT)
Subject: [LLVMdev] Several basic questions about Builder
In-Reply-To: <f5aa3e9b0906280239g1fedaca0w86d523d948de9cf9@mail.gmail.com>
Message-ID: <30419.86186.qm@web50102.mail.re2.yahoo.com>


Thanks I managed to figure out most of basic points here based on these answers.

--- On Sun, 6/28/09, Eli Friedman <eli.friedman at gmail.com> wrote:

> From: Eli Friedman <eli.friedman at gmail.com>
> Subject: Re: [LLVMdev] Several basic questions about Builder
> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
> Date: Sunday, June 28, 2009, 2:39 AM
> On Sun, Jun 28, 2009 at 1:05 AM,
> Carter Cheng<carter_cheng at yahoo.com>
> wrote:
> > 1) Using the Builder interface how does one create the
> equivalent of stack frames and access variables in the
> current stack frame or perhaps in the static enclosing scope
> (assuming functions can be nested)?
> 
> To create stack variables, you can use the alloca
> instruction; see
> http://llvm.org/docs/tutorial/LangImpl7.html#memory .
> 
> LLVM doesn't directly support nested functions; you'll have
> to lower
> them yourself.  For example, try something like the
> following in the
> LLVM demo page (http://llvm.org/demo/index.cgi) with
> optimization off:
> int main(int argc, char **argv) {
>   void a(int x) { if (x == 10) return; a(x+1); argc +=
> x; }
>   a(0);
>   return argc;
> }
> 
> > 2) Is it possible to deallocate functions from a
> module and recycle the memory used without restarting the
> JIT? I am trying to build a server type application where
> objects/classes maybe be deallocated and thus the associated
> functions will no longer be used.
> 
> That should be possible; I'm not sure of the details,
> though.
> 
> > 3) How does one sequence instructions using Builder
> similar to a semi-colon in a language like C?
> 
> Instructions are ordered within a basic block, and they are
> guaranteed
> to be executed in that order.  If you just build the
> instructions in
> the same order that the statements occur in the code, it
> should work
> without any special tweaking.
> 
> -Eli
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu 
>        http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 


      



From linus_wind at zju.edu.cn  Mon Jun 29 01:16:36 2009
From: linus_wind at zju.edu.cn (Wenzhi Tao)
Date: Mon, 29 Jun 2009 16:16:36 +0800
Subject: [LLVMdev] Limitations of Alias Analysis?
Message-ID: <446261587.07109@zju.edu.cn>

Hi, all

  According to the document "LLVM Alias Analysis Infrastructure", I
evaluated the AA performance by using the paramenters '-basicaa -ds-aa
-anders-aa'. The source code 'test.c' is listed as follow:

//------------===  Source code  ===------------//
#include<stdlib.h>

typedef struct
{
	int x;
	int y;
} Location;

Location* getNewLocation(int x, int y)
{
	Location* newLoc = (Location *)malloc(sizeof(Location));
	
	newLoc->x = x;
	newLoc->y = y;
	return newLoc;
}

Location* getDifference(Location *a, Location *b) 
{
	Location* newLoc = (Location *)malloc(sizeof(Location));
	
	newLoc->x = a->x - b->x;
	newLoc->y = a->y - b->y;
	return newLoc;
}

int main()
{
	Location *loc1 = getNewLocation(0, 0);
	Location *loc2 = getNewLocation(1, 2);
	Location *loc3 = getDifference(loc1, loc2);
	
	free(loc1);
	free(loc2);
	free(loc3);
	
	return 0;
}
//------------===  End  ===------------//
The whole process:

llvm-gcc -emit-llvm -O0 -c test.c -o test.bc

opt test.bc -load libLLVMDataStructure.so -basic-aa -ds-aa -anders-aa
-aa-eval -print-all-alias-modref-info

The corresponding IR content of main is:

define i32 @main() nounwind {
entry:
	%retval = alloca i32		
	%loc3 = alloca %struct.Location*		
	%loc2 = alloca %struct.Location*		
	%loc1 = alloca %struct.Location*		
	%0 = alloca i32		
	%"alloca point" = bitcast i32 0 to i32		
	%1 = call %struct.Location* @getNewLocation(i32 0, i32 0) nounwind
	store %struct.Location* %1, %struct.Location** %loc1, align 4
	%2 = call %struct.Location* @getNewLocation(i32 1, i32 2) nounwind
	store %struct.Location* %2, %struct.Location** %loc2, align 4
	%3 = load %struct.Location** %loc1, align 4		
	%4 = load %struct.Location** %loc2, align 4		
	%5 = call %struct.Location* @sub(%struct.Location* %3, %
struct.Location* %4) nounwind		
	store %struct.Location* %5, %struct.Location** %loc3, align 4
	%6 = load %struct.Location** %loc1, align 4		
	%7 = bitcast %struct.Location* %6 to i8*		
	call void @free(i8* %7) nounwind
	%8 = load %struct.Location** %loc2, align 4		
	%9 = bitcast %struct.Location* %8 to i8*		
	call void @free(i8* %9) nounwind
	%10 = load %struct.Location** %loc3, align 4		
	%11 = bitcast %struct.Location* %10 to i8*		
	call void @free(i8* %11) nounwind
	store i32 0, i32* %0, align 4
	%12 = load i32* %0, align 4
	store i32 %12, i32* %retval, align 4
	br label %return

return:		; preds = %entry
	%retval1 = load i32* %retval
	ret i32 %retval1
}

The analysis result of function main is(Strip NoAlias):

  MayAlias:	%struct.Location* %1, %struct.Location* %2

But, in my opinion, %1 and %2 should be NoAlias. And, there's no
dependence between 
%1 = call %struct.Location* @getNewLocation(i32 0, i32 0) nounwind
              and
%2 = call %struct.Location* @getNewLocation(i32 1, i32 2) nounwind


%1 and %2 are considered as MayAlias results that while using
llvm::MemoryDependenceAnalysis, %2 is dependent on %1(clobber). But in
fact it's not.

Maybe a flow-sensitive, context-sensitive alias analysis algorithm is
needed to generate more precise result? Correct me, if I'm wrong. Thank
you.



From baldrick at free.fr  Mon Jun 29 01:36:55 2009
From: baldrick at free.fr (Duncan Sands)
Date: Mon, 29 Jun 2009 10:36:55 +0200
Subject: [LLVMdev] Limitations of Alias Analysis?
In-Reply-To: <446261587.07109@zju.edu.cn>
References: <446261587.07109@zju.edu.cn>
Message-ID: <4A487D27.4040201@free.fr>

Hi,

> llvm-gcc -emit-llvm -O0 -c test.c -o test.bc

try compiling with optimization.

Ciao,

Duncan.


From Olaf.Krzikalla at tu-dresden.de  Mon Jun 29 01:45:11 2009
From: Olaf.Krzikalla at tu-dresden.de (Olaf Krzikalla)
Date: Mon, 29 Jun 2009 10:45:11 +0200
Subject: [LLVMdev] [cfe-dev] Patch for llvm::DepthFirstIterator.h and
 llvm::PostOrderIterator.h
In-Reply-To: <6A4C1440-4054-4EE1-A21E-CF6A55AEE8A1@apple.com>
References: <4A44BFEC.9050301@tu-dresden.de>
	<6A4C1440-4054-4EE1-A21E-CF6A55AEE8A1@apple.com>
Message-ID: <4A487F17.7010901@tu-dresden.de>

Hi,

I've done all the minor changes you recommended and have attached a new 
patch including both files again (even if po_iterator didn't change).
However:

Dan Gohman schrieb:
> The plural of "child" is "children"; please rename this function
> accordingly.  
Is "childs" just sloppy, is it american english or is it just a 
misconception of foreigners like me?
I think I've already seen it somewhere.

Best
Olaf

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: llvm-iterator.patch
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090629/c9a70367/attachment.ksh>

From edwintorok at gmail.com  Mon Jun 29 01:48:52 2009
From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=)
Date: Mon, 29 Jun 2009 11:48:52 +0300
Subject: [LLVMdev] Limitations of Alias Analysis?
In-Reply-To: <446261587.07109@zju.edu.cn>
References: <446261587.07109@zju.edu.cn>
Message-ID: <4A487FF4.9060007@gmail.com>

On 2009-06-29 11:16, Wenzhi Tao wrote:
> Hi, all
>
>   According to the document "LLVM Alias Analysis Infrastructure", I
> evaluated the AA performance by using the paramenters '-basicaa -ds-aa
> -anders-aa'. The source code 'test.c' is listed as follow:
> [...] 
> The whole process:
>
> llvm-gcc -emit-llvm -O0 -c test.c -o test.bc
>
> opt test.bc -load libLLVMDataStructure.so -basic-aa -ds-aa -anders-aa
> -aa-eval -print-all-alias-modref-info
>   

Try this:
opt -mem2reg -functionattrs -basic-aa -aa-eval
-print-all-alias-modref-info test.bc

It shows:
  NoAlias:      %struct.Location* %0, %struct.Location* %1

> %1 and %2 are considered as MayAlias results that while using
> llvm::MemoryDependenceAnalysis, %2 is dependent on %1(clobber). But in
> fact it's not.
>
> Maybe a flow-sensitive, context-sensitive alias analysis algorithm is
> needed to generate more precise result? Correct me, if I'm wrong. Thank
> you.
>   

Running the functionattrs pass should be enough to add the 'noalias'
marker on getNewLocation(), and then even basic-aa can see that loc1 and
loc2 are NoAlias.
You also need to run -mem2reg, because otherwise -functionattrs doesn't
see that the return value is coming from a malloc (which already has
noalias attribute).

Best regards,
--Edwin



From eli.friedman at gmail.com  Mon Jun 29 03:08:39 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Mon, 29 Jun 2009 03:08:39 -0700
Subject: [LLVMdev] Pinning registers in LLVM
In-Reply-To: <F8C491D7-1C02-4C61-B690-1D62346EA9F6@gmail.com>
References: <F8C491D7-1C02-4C61-B690-1D62346EA9F6@gmail.com>
Message-ID: <f5aa3e9b0906290308r61572ewba05bfdecab02ca@mail.gmail.com>

On Sun, Jun 28, 2009 at 11:00 PM, David Terei<davidterei at gmail.com> wrote:
> So just hoping this can be done with LLVM and if so, then how.

Despite the fact that llvm-gcc accepts the given code, the extension
isn't properly supported; the current output is close to correct, but
not quite.  The issue is that the register allocator isn't aware of
the global register, and can allocate other values into it.  Patches
welcome, I guess, although off the top of my head, I'm not sure what
the best way to go about implementing it would be.

-Eli


From eli.friedman at gmail.com  Mon Jun 29 03:15:36 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Mon, 29 Jun 2009 03:15:36 -0700
Subject: [LLVMdev] [cfe-dev] Patch for llvm::DepthFirstIterator.h and
	llvm::PostOrderIterator.h
In-Reply-To: <4A487F17.7010901@tu-dresden.de>
References: <4A44BFEC.9050301@tu-dresden.de>
	<6A4C1440-4054-4EE1-A21E-CF6A55AEE8A1@apple.com>
	<4A487F17.7010901@tu-dresden.de>
Message-ID: <f5aa3e9b0906290315k2cdb6249x5828db677937099f@mail.gmail.com>

On Mon, Jun 29, 2009 at 1:45 AM, Olaf
Krzikalla<Olaf.Krzikalla at tu-dresden.de> wrote:
> Dan Gohman schrieb:
>>
>> The plural of "child" is "children"; please rename this function
>> accordingly.
>
> Is "childs" just sloppy, is it american english or is it just a
> misconception of foreigners like me?
> I think I've already seen it somewhere.

"Childs" is a last name, and "child's" is posessive, but no native
English speaker would ever use "childs".

-Eli


From carter_cheng at yahoo.com  Mon Jun 29 03:37:22 2009
From: carter_cheng at yahoo.com (Carter Cheng)
Date: Mon, 29 Jun 2009 03:37:22 -0700 (PDT)
Subject: [LLVMdev] JIT question about resolving unknown function calls
Message-ID: <650920.94987.qm@web50112.mail.re2.yahoo.com>


My understanding is that the JIT system allows during the running of the system resolution of call instructions to undefined functions to be trapped and then patched with the correct address (is this true?). 

The question I have is does the current system also allow for repatching? for a certain OO system I am working on this could be desirable when an object/class is updated and replaced- making it possible in certain cases to update the call point as the code is replaced. 

Thanks in advance. 


      


From mcheva at cs.mcgill.ca  Mon Jun 29 05:54:26 2009
From: mcheva at cs.mcgill.ca (Nyx)
Date: Mon, 29 Jun 2009 05:54:26 -0700 (PDT)
Subject: [LLVMdev]  Instruction Combining Pass *Breaking* Struct Reads?
Message-ID: <24253572.post@talk.nabble.com>


I'm in a situation where I have code that works fine if I don't run the
instruction combining optimization pass, but breaks when I do. The code in
question is meant to allocate space for two structs on the stack using
alloca, and then pass pointers to these to a callee function. One struct
serves to store the input to the function, the other serves for the callee
function to write its output. This is part of my calling mechanism. Once the
call is terminated, the caller will read from the output struct. The twist
is that I am not allocating the structs directly, I am allocating buffers of
bytes and casting the pointers into struct pointers.

The following snipper is without instruction combining being run:

	%2 = alloca i8, i32 16		; <i8*> [#uses=1]
	%3 = alloca i8, i32 12		; <i8*> [#uses=1]
	%4 = call i8* @"Environment::extend"(i8* inttoptr (i32 173374432 to i8*))	
; <i8*> [#uses=3]
	%5 = call i8* @"ArrayObj::create"(i32 0)		; <i8*> [#uses=1]
	%6 = call i8* @"Interpreter::callFunction"(i8* inttoptr (i32 147457088 to
i8*), i8* %5, i32 0)		; <i8*> [#uses=0]
	%7 = bitcast i8* %2 to { i64, i64 }*		; <{ i64, i64 }*> [#uses=3]
	%8 = bitcast i8* %3 to { i8*, i64 }*		; <{ i8*, i64 }*> [#uses=3]
	%9 = getelementptr { i64, i64 }* %7, i32 0, i32 0		; <i64*> [#uses=1]
	store i64 25, i64* %9
	%10 = getelementptr { i64, i64 }* %7, i32 0, i32 1		; <i64*> [#uses=1]
	store i64 1, i64* %10
	call void @fibonacci_0xa566d80({ i64, i64 }* %7, { i8*, i64 }* %8)
	%11 = getelementptr { i8*, i64 }* %8, i32 0, i32 1		; <i64*> [#uses=1]
	%12 = load i64* %11		; <i64> [#uses=1]
	%13 = icmp slt i64 %12, 1		; <i1> [#uses=1]
	br i1 %13, label %21, label %14

As you can see, I allocate two structs, one taking 16 bytes (containing two
i64 values), and one taking 12 bytes (containing a pointer and an i64 value,
this is on a 32-bit machine). I then cast those pointers to the proper
struct types (see values %7 and %8). I then call the fibonacci function, and
after that, I read the i64 value of the second struct (see values %11, %12)
and branch based on its value. This code works just fine when I run it.

Now, if I run the instruction combining pass, the above code gets turned
into this:

	%2 = alloca { i64, i64 }, align 8		; <{ i64, i64 }*> [#uses=3]
	%3 = alloca [12 x i8], align 1		; <[12 x i8]*> [#uses=3]
	%4 = call i8* @"Environment::extend"(i8* inttoptr (i32 148577248 to i8*))	
; <i8*> [#uses=3]
	%5 = call i8* @"ArrayObj::create"(i32 0)		; <i8*> [#uses=1]
	%6 = call i8* @"Interpreter::callFunction"(i8* inttoptr (i32 147883136 to
i8*), i8* %5, i32 0)		; <i8*> [#uses=0]
	%7 = bitcast [12 x i8]* %3 to { i8*, i64 }*		; <{ i8*, i64 }*> [#uses=1]
	%8 = getelementptr { i64, i64 }* %2, i64 0, i32 0		; <i64*> [#uses=1]
	store i64 25, i64* %8, align 8
	%9 = getelementptr { i64, i64 }* %2, i64 0, i32 1		; <i64*> [#uses=1]
	store i64 1, i64* %9, align 8
	call void @fibonacci_0x8dc0d80({ i64, i64 }* %2, { i8*, i64 }* %7)
	%10 = getelementptr [12 x i8]* %3, i64 0, i64 8		; <i8*> [#uses=1]
	%11 = bitcast i8* %10 to i64*		; <i64*> [#uses=1]
	%12 = load i64* %11		; <i64> [#uses=1]
	%13 = icmp slt i64 %12, 1		; <i1> [#uses=1]
	br i1 %13, label %21, label %14

This code does not work properly. If we take a look at value %10, we can see
that it tries to read a value at offset 8! This is obviously wrong, as the
value is an i64, and the size of the output struct is 12! Thus, the value
should be read at offset 4, not 8!

And here I find myself puzzled. I know the second struct really has size 12.
I know the alignment is 4. Why is it that the instruction combining pass
tries to read a value at offset 8, as if the pointer inside the output
struct took 8 bytes? Furthermore, why does it allocate one struct as a
struct, and one as a byte array? Is there a bug in this optimization pass,
or am I doing something wrong? Note that I am using LLVM version 2.5.

Any help would be appreciated!

- Max
-- 
View this message in context: http://www.nabble.com/Instruction-Combining-Pass-*Breaking*-Struct-Reads--tp24253572p24253572.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.



From e0325716 at student.tuwien.ac.at  Mon Jun 29 06:34:04 2009
From: e0325716 at student.tuwien.ac.at (Andreas Neustifter)
Date: Mon, 29 Jun 2009 15:34:04 +0200
Subject: [LLVMdev] Profiling in LLVM Patch
Message-ID: <4A48C2CC.4060708@student.tuwien.ac.at>

Hi all,

as proposed in
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-February/020396.html
I implemented the algorithm presented in [Ball94]. It only instruments
the minimal number of edges necessary for edge profiling.

The main changes introduced by this patch are:
*) a interface compatible rewrite of ProfileInfo
*) a cleanup of ProfileInfoLoader
    (some functionality in ProfileInfoLoader was duplicated in ProfileInfo or
    ProfileInfoLoaderPass; ProfileInfoLoader now really only performs the
    loading but not the post-processing)
*) a new instrumentation pass that performs the optimal edge profiling
    instrumentation
*) a helper module MaximumSpanningTree that selects the edges with have to
    be instrumented for optimal edge profiling
*) a ProfileEstimatorPass that does an offline estimation of a profile based
    on branching and loop depth (also proposed in [Ball94])
    (it is possible to use this ProfileEstimator stand-alone to have at least
    some profile estimation available in the frontend without doing profiling
    runs)
*) a ProfileVerifierPass that checks the current profiling information
    against the flow preservation rules

I did performance measurements on the C and C++ portions of the SPEC CPU2000
benchmark, the results are:
*) on average 46% of the edges are instrumented with a counter (in
    comparison to 100% with the current edge profiling)
*) the performance overhead (on linux-x68_64, other platforms to follow) was
    14.76% with the current profiling and 8.20% with the optimal profiling
    (there are strange effects with the mcf and equake benchmarks where the
    current edge profiling is as fast as the un-instrumented code whereas the
    optimally instrumented code has a small (~5%) performance overhead)
*) when mcf and equake are excluded the average performance overhead is
    51.31% with optimal profiling (in comparison to 100% with the current
    edge profiling)

Please tell me what you do not like and if this is interesting enough to be
added to the trunk, if so, I will also devise test cases for "make check".

If you do not like the size of this patch it is possible to break it up a
little. I did not use the mkpatch utility since it does not include added
files, I hope the format is readable enough (it should be...)

I ran "make check" and there are not additional errors introduced
by the patch.

Grettings,

Andreas Neustifter

[Ball94] Thomas Ball, James R. Larus:
"Optimally profiling and tracing programs"
ACM TOPLAS, Volume 16, Issue 4, 1994
http://portal.acm.org/citation.cfm?id=183527
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-r74306.optimal_profiling.patch
Type: text/x-patch
Size: 85518 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090629/9d908488/attachment.bin>

From mwwhalen at rockwellcollins.com  Mon Jun 29 06:51:20 2009
From: mwwhalen at rockwellcollins.com (mwwhalen at rockwellcollins.com)
Date: Mon, 29 Jun 2009 08:51:20 -0500
Subject: [LLVMdev] Michael W Whalen is out of the office.
Message-ID: <OF6E44BAF6.8CECAA18-ON862575E4.004C1CA3-862575E4.004C1CA3@rockwellcollins.com>


I will be out of the office starting  06/29/2009 and will not return until
07/06/2009.

During this time I will be checking my email or voice mails sporadically.
If you have an urgent request, please contact Matt Wilding at
mmwildin at rockwellcollins.com



From davidterei at gmail.com  Mon Jun 29 07:02:34 2009
From: davidterei at gmail.com (David Terei)
Date: Tue, 30 Jun 2009 00:02:34 +1000
Subject: [LLVMdev] Pinning registers in LLVM
In-Reply-To: <f5aa3e9b0906290308r61572ewba05bfdecab02ca@mail.gmail.com>
References: <F8C491D7-1C02-4C61-B690-1D62346EA9F6@gmail.com> 
	<f5aa3e9b0906290308r61572ewba05bfdecab02ca@mail.gmail.com>
Message-ID: <150b8f420906290702r7053028w1148f1b9f3e12caa@mail.gmail.com>

Thanks for the response.

2009/6/29 Eli Friedman <eli.friedman at gmail.com>
> The issue is that the register allocator isn't aware of
> the global register, and can allocate other values into it.

So in that case there is no way currently to pin to registers then? I
won't be working with llvm-gcc, using llvm directly, was just trying
to figure out how llvm supported this feature by studying the llvm
byte code it produces.

> Patches welcome, I guess, although off the top of my head, I'm not sure what
> the best way to go about implementing it would be.

Any idea of the difficulty this would involve (ruff guess of time it
would take?). Need to decide if it would be better to add support to
llvm for this feature or change GHC such that it isn't needed.

Cheers,
David


From eli.friedman at gmail.com  Mon Jun 29 07:52:31 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Mon, 29 Jun 2009 07:52:31 -0700
Subject: [LLVMdev] Instruction Combining Pass *Breaking* Struct Reads?
In-Reply-To: <24253572.post@talk.nabble.com>
References: <24253572.post@talk.nabble.com>
Message-ID: <f5aa3e9b0906290752p69982846j9e77d2c6bfba6a21@mail.gmail.com>

On Mon, Jun 29, 2009 at 5:54 AM, Nyx<mcheva at cs.mcgill.ca> wrote:
> As you can see, I allocate two structs, one taking 16 bytes (containing two
> i64 values), and one taking 12 bytes (containing a pointer and an i64 value,
> this is on a 32-bit machine)

Are you sure that's right?  If the target data specifies that a
pointer is 64 bits or that i64 has an alignment of 64 bits, this code
is isn't allocating enough space for the struct.

-Eli


From mcheva at cs.mcgill.ca  Mon Jun 29 08:32:51 2009
From: mcheva at cs.mcgill.ca (Nyx)
Date: Mon, 29 Jun 2009 08:32:51 -0700 (PDT)
Subject: [LLVMdev] Instruction Combining Pass *Breaking* Struct Reads?
In-Reply-To: <f5aa3e9b0906290752p69982846j9e77d2c6bfba6a21@mail.gmail.com>
References: <24253572.post@talk.nabble.com>
	<f5aa3e9b0906290752p69982846j9e77d2c6bfba6a21@mail.gmail.com>
Message-ID: <24256244.post@talk.nabble.com>


I just found what the problem was. I was using a different target data for
the optimization passes (creating a new one for the optimization passes) Not
the target data from the execution engine... So the instruction combining
pass was working with erroneous information, since by default it seems to
assume pointers are 64 bits. Problem fixed!

- Max


Eli Friedman-2 wrote:
> 
> On Mon, Jun 29, 2009 at 5:54 AM, Nyx<mcheva at cs.mcgill.ca> wrote:
>> As you can see, I allocate two structs, one taking 16 bytes (containing
>> two
>> i64 values), and one taking 12 bytes (containing a pointer and an i64
>> value,
>> this is on a 32-bit machine)
> 
> Are you sure that's right?  If the target data specifies that a
> pointer is 64 bits or that i64 has an alignment of 64 bits, this code
> is isn't allocating enough space for the struct.
> 
> -Eli
> _______________________________________________
> 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://www.nabble.com/Instruction-Combining-Pass-*Breaking*-Struct-Reads--tp24253572p24256244.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.



From artjom.kochtchi at googlemail.com  Mon Jun 29 09:00:00 2009
From: artjom.kochtchi at googlemail.com (Artjom Kochtchi)
Date: Mon, 29 Jun 2009 09:00:00 -0700 (PDT)
Subject: [LLVMdev] Inserting nodes into SelectionDAG (X86)
In-Reply-To: <5B6FAE89-05DC-44D9-B932-7B8A1927DCE3@apple.com>
References: <24211066.post@talk.nabble.com>
	<07E3436A-6277-4CD3-B44D-D7F2A9BA2675@apple.com>
	<24218876.post@talk.nabble.com>
	<5B6FAE89-05DC-44D9-B932-7B8A1927DCE3@apple.com>
Message-ID: <24256897.post@talk.nabble.com>


Sorry to ask again, but I still can't get it right.

The following code compiles and runs, but produces no instructions:
  Ops.push_back(DAG.getRegister(X86::EAX, MVT::i32));
  Ops.push_back(DAG.getConstant(1, MVT::i32));
  DAG.getNode(ISD::ADD, DAG.getVTList(MVT::i32), &Ops[0], Ops.size());

I reckon that has something to do with the fact that I am not using the
Chain object. But as soon as I try to chain that node, llc tells me that I
have the wrong number of operands:
  Ops.push_back(Chain);
  Ops.push_back(DAG.getRegister(X86::EAX, MVT::i32));
  Ops.push_back(DAG.getConstant(1, MVT::i32));
  Chain = DAG.getNode(ISD::ADD, DAG.getVTList(MVT::Other, MVT::i32),
&Ops[0], Ops.size());

Isn't that the way how it is supposed to work?

Artjom
-- 
View this message in context: http://www.nabble.com/Inserting-nodes-into-SelectionDAG-%28X86%29-tp24211066p24256897.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.



From tema13tema at yahoo.de  Mon Jun 29 08:55:02 2009
From: tema13tema at yahoo.de (Rudskyy)
Date: Mon, 29 Jun 2009 17:55:02 +0200
Subject: [LLVMdev] About debug in LLVM!!!
Message-ID: <000901c9f8d1$f7590730$07362c8d@MOIPC7>

Hi all LLVMdev!

 

Here is a question: 

I try to understand how I can realize a debugging in LLVM!?

I have written a back end for my target and now I need a debug.

I asked developers Chris Lattner and Robert L. Bocchino. They recommend me
ask the LLVMdev.

Is there a tool like "llvm-db" about Robert said?

Here a mail from Robert:

 

On Jun 29, 2009, at 17:14 PM, Robert L. Bocchino Jr wrote:

 

Hi Artem, 

Thanks for your interest in LLVM.  I haven't ever used LLVM for source-level
debugging.  From scanning that page (SourceLevelDebugging.html) it seems to
describe the format that LLVM bytecode uses to encode debug information, but
it doesn't say anything about what tool to use or how to use it to actually
to the debugging.  I think gdb would not work with this, because gdb doesn't
understand anything about the LLVM bytecode representation -- you'd need
some gdb-like tool that works with LLVM this way.  I seem to recall there
was a tool "llvm-db" but I don't see that described on the site now.  I
think your best bet is to email llvm-dev with this question, or maybe ask
Chris Lattner or Jim Laskey (the authors of the debug info document) to
point you in the right direction.

 

Rob

 

 

On Jun 26, 2009, at 1:21 PM, Rudskyy wrote:

 

Hallo, Robert L. Bocchino Jr.!

I have found you in LLVM Developers page (http://llvm.org/developers.cgi).

First thank you for all of your work with LLVM.

 

About:

I work with the LLVM Compiler Infrastructure to implement a backend for
specific processor xPEC of chip NetX (http://hilscher.com/netx..html
<http://hilscher.com/netx.html> ).

So C-code already possible compile to the native xPEC assembly code (works
perfect! LLWM a big power!).

Now I need to debug the source C-code, that I compile for xPEC-processor. I
have read the article "Source Level Debugging with LLVM"
(http://llvm.org/docs/SourceLevelDebugging.html), where were described that
is possible to use debugger GDB. Wonderful! I have found much information
about GDB (of coursehttp://sourceware.org/gdb/ ) and it has a debugging of
remote programs.

Problem:

I don't understand how must be compiled the C-code with "llvm-gcc". Wenn I
use option "-emit-llvm" [backend needs it] of course with "-g" and "-O0",
then GDB can't find a symbol table in bc-file.  Where will place "llvm-gcc"
the symbol table for DGB? Perhaps, must GDB knows the architecture of
processor? If yes, so where it must be written?   I have many questions and
need some help.

Do you can help me what must I read and search ore recommend somebody to
can?

  

Best regards,

Artem Rudskyy

http://www..uni-magdeburg.de/ieat/robotslab/
<http://www.uni-magdeburg.de/ieat/robotslab/> 

http://www.uni-magdeburg.de/

 

 

Robert L. Bocchino Jr.

Ph.D. Student

University of Illinois, Urbana-Champaign

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090629/4f35f509/attachment.html>

From sanjiv.gupta at microchip.com  Mon Jun 29 09:36:42 2009
From: sanjiv.gupta at microchip.com (Sanjiv Gupta)
Date: Mon, 29 Jun 2009 22:06:42 +0530
Subject: [LLVMdev] llvmc for PIC16
In-Reply-To: <3cb898890906180430k5cb0d57fh7c66d10a45c50db0@mail.gmail.com>
References: <4A2633E9.4070207@microchip.com>	
	<loom.20090604T142600-116@post.gmane.org>	
	<4A28C062.9060307@microchip.com>	
	<loom.20090607T070933-452@post.gmane.org>	
	<4A35EA76.7090602@microchip.com>	
	<3cb898890906150348l2e0d4095seb54de38f95e69f9@mail.gmail.com>	
	<4A3656A3.1050403@microchip.com>	
	<3cb898890906150730k534167dfxf59677e966477220@mail.gmail.com>	
	<4A39F1D7.4060101@microchip.com>
	<3cb898890906180430k5cb0d57fh7c66d10a45c50db0@mail.gmail.com>
Message-ID: <4A48ED9A.2040403@microchip.com>

Mikhail Glushenkov wrote:
> Hi Sanjiv,
>
> 2009/6/18 Sanjiv Gupta <sanjiv.gupta at microchip.com>:
>   
>> Hi Mikhail,
>> Thanks for your wonderful help so far. I have few more questions to ask:
>>
>> How do I modify the driver to pick tools from where the driver itself
>> resides, rather than from the PATH?
>> Do I need to write some C++ code to customize such behaviors?
>>     
>
> Yes, this is what hooks are for. You're supposed to change the
> cmd_line property to something like this:
>
> (cmd_line "$CALL(PrependCustomizedPath, 'toolname') --tool --options")
>
> The PrependCustomizedPath function above is implemented in C++ (just
> drop a .cpp file into the plugin directory).
>
>   
Hi Mikhail,

I want to retrieve the value of argv[0] (which was passed to main 
function of the driver) in PrependCustomizedPath.
Do we have some standard name for argv[0] in tablegen?

- Sanjiv



From clattner at apple.com  Mon Jun 29 10:18:49 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 29 Jun 2009 10:18:49 -0700
Subject: [LLVMdev] JIT question about resolving unknown function calls
In-Reply-To: <650920.94987.qm@web50112.mail.re2.yahoo.com>
References: <650920.94987.qm@web50112.mail.re2.yahoo.com>
Message-ID: <9A3A0323-234A-4B20-BBE9-F1DC8FA608BE@apple.com>


On Jun 29, 2009, at 3:37 AM, Carter Cheng wrote:

>
> My understanding is that the JIT system allows during the running of  
> the system resolution of call instructions to undefined functions to  
> be trapped and then patched with the correct address (is this true?).

Yes, see:
http://llvm.org/docs/tutorial/LangImpl4.html#jit

> The question I have is does the current system also allow for  
> repatching? for a certain OO system I am working on this could be  
> desirable when an object/class is updated and replaced- making it  
> possible in certain cases to update the call point as the code is  
> replaced.

You can repatch a function that was hitted with the  
ExecutionEngine::recompileAndRelinkFunction method.  If you have a  
symbol that isn't JIT'd that you want to move around, just define a  
global that holds the pointer, and change the pointer as you wish.

-Chris


From sanjiv.gupta at microchip.com  Mon Jun 29 10:20:37 2009
From: sanjiv.gupta at microchip.com (Sanjiv Gupta)
Date: Mon, 29 Jun 2009 22:50:37 +0530
Subject: [LLVMdev] About debug in LLVM!!!
In-Reply-To: <000901c9f8d1$f7590730$07362c8d@MOIPC7>
References: <000901c9f8d1$f7590730$07362c8d@MOIPC7>
Message-ID: <4A48F7E5.4030002@microchip.com>

Do you want to debug the native executables generated by your back-end?
What debug info format your native executables support?
In general, this is how it works for that case.

1. clang-cc -g generates required debug info in the .bc file.
2. The backend (llc) converts that to Dwarf (or something else as 
desired by that back-end).
3. Native debuggers like (gdb) understands Dwarf and provide source 
level debugging eventually.

- Sanjiv

Rudskyy wrote:
>
> Hi all LLVMdev!
>
> Here is a question:
>
> I try to understand how I can realize a debugging in LLVM!?
>
> I have written a back end for my target and now I need a debug.
>
> I asked developers Chris Lattner and Robert L. Bocchino. They 
> recommend me ask the LLVMdev.
>
> Is there a tool like "llvm-db" about Robert said?
>
> Here a mail from Robert:
>
> _On Jun 29, 2009, at 17:14 PM, Robert L. Bocchino Jr wrote:_
>
> Hi Artem,
>
> Thanks for your interest in LLVM. I haven't ever used LLVM for 
> source-level debugging. From scanning that page 
> (SourceLevelDebugging.html) it seems to describe the format that LLVM 
> bytecode uses to encode debug information, but it doesn't say anything 
> about what tool to use or how to use it to actually to the debugging. 
> I think gdb would not work with this, because gdb doesn't understand 
> anything about the LLVM bytecode representation -- you'd need some 
> gdb-like tool that works with LLVM this way. I seem to recall there 
> was a tool "llvm-db" but I don't see that described on the site now. I 
> think your best bet is to email llvm-dev with this question, or maybe 
> ask Chris Lattner or Jim Laskey (the authors of the debug info 
> document) to point you in the right direction.
>
> Rob
>
> _On Jun 26, 2009, at 1:21 PM, Rudskyy wrote:_
>
> /Hallo, Robert L. Bocchino Jr.!///
>
> /I have found you in LLVM Developers page 
> (http://llvm.org/developers.cgi).///
>
> /First thank you for all of your work with LLVM.///
>
> / ///
>
> /About:///
>
> /I work with the **LLVM** Compiler Infrastructure to implement a 
> backend for specific processor xPEC of chip NetX 
> (http://hilscher.com/netx...html <http://hilscher.com/netx.html>).///
>
> /So C-code already possible compile to the native xPEC assembly code 
> (works perfect! LLWM a big power!).///
>
> /Now I need to debug the source C-code, that I compile for 
> xPEC-processor. I have read the article “Source Level Debugging with 
> LLVM” (http://llvm.org/docs/SourceLevelDebugging.html), where were 
> described that is possible to use debugger GDB. Wonderful! I have 
> found much information about GDB (of coursehttp://sourceware.org/gdb/ 
> ) and it has a debugging of remote programs.///
>
> /Problem:///
>
> /I don’t understand how must be compiled the C-code with “llvm-gcc”. 
> Wenn I use option “-emit-llvm” [backend needs it] of course with “-g” 
> and “-O0”, then GDB can’t find a symbol table in bc-file. Where will 
> place “llvm-gcc” the symbol table for DGB? Perhaps, must GDB knows the 
> architecture of processor? If yes, so where it must be written? I have 
> many questions and need some help.///
>
> /Do you can help me what must I read and search ore recommend somebody 
> to can?///
>
> / ///
>
> /Best regards,///
>
> /Artem Rudskyy///
>
> /http://www...uni-magdeburg.de/ieat/robotslab/ 
> <http://www.uni-magdeburg.de/ieat/robotslab/>///
>
> /http://www.uni-magdeburg.de////
>
> Robert L. Bocchino Jr.
>
> Ph.D. Student
>
> University of Illinois, Urbana-Champaign
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   



From samuraileumas at yahoo.com  Mon Jun 29 10:28:18 2009
From: samuraileumas at yahoo.com (Samuel Crow)
Date: Mon, 29 Jun 2009 10:28:18 -0700 (PDT)
Subject: [LLVMdev] About debug in LLVM!!!
In-Reply-To: <000901c9f8d1$f7590730$07362c8d@MOIPC7>
References: <000901c9f8d1$f7590730$07362c8d@MOIPC7>
Message-ID: <65455.85775.qm@web62001.mail.re1.yahoo.com>

Hello,

I'm not sure whether Bugpoint does what you are looking for but it comes with LLVM.  It's documentation is found at http://llvm.org/cmds/bugpoint.html so if you want to look into that, that may answer your question.  It's the closest thing I've found to an LLVM debugging tool.

Sorry I can't help more than this.

--Sam

Here is a question: 
>I try to understand how I can realize a debugging in
>LLVM!?
>I have written a back end for my target and now I need
>a debug.
>I asked developers Chris Lattner and Robert L. Bocchino. They recommend me ask
>the LLVMdev.
>Is therea tool like "llvm-db" about Robert said?
>Here a mail from Robert:
> 
>


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090629/af2d66c5/attachment.html>

From the.dead.shall.rise at gmail.com  Mon Jun 29 10:33:51 2009
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Mon, 29 Jun 2009 19:33:51 +0200
Subject: [LLVMdev] llvmc for PIC16
In-Reply-To: <4A48ED9A.2040403@microchip.com>
References: <4A2633E9.4070207@microchip.com> <4A28C062.9060307@microchip.com>
	<loom.20090607T070933-452@post.gmane.org>
	<4A35EA76.7090602@microchip.com>
	<3cb898890906150348l2e0d4095seb54de38f95e69f9@mail.gmail.com>
	<4A3656A3.1050403@microchip.com>
	<3cb898890906150730k534167dfxf59677e966477220@mail.gmail.com>
	<4A39F1D7.4060101@microchip.com>
	<3cb898890906180430k5cb0d57fh7c66d10a45c50db0@mail.gmail.com>
	<4A48ED9A.2040403@microchip.com>
Message-ID: <3cb898890906291033j32dff53ajae0d6823cabb08f4@mail.gmail.com>

Hi Sanjiv,

2009/6/29 Sanjiv Gupta <sanjiv.gupta at microchip.com>:
> Hi Mikhail,
>
> I want to retrieve the value of argv[0] (which was passed to main function
> of the driver) in PrependCustomizedPath.
> Do we have some standard name for argv[0] in tablegen?

This is not possible ATM, but is easy to add (assign argv to a global
variable Argv in main, then refer to Argv via an extern declaration in
PrependCustomizedPath; btw, the same mechanism can be used to refer to
command-line options).

On the other hand, you shouldn't have to condition on argv[0]. Look at
what the Base plugin does to choose the correct linker options (think
'gcc' versus 'g++'). By default, this information is deduced from the
input file names (if there are files ending with .cpp/.cxx/etc, we
choose the C++ linker), but the C++ linker can also be forced with the
-linker=c++ option. Then the analog of the 'g++' command can be
implemented as an alias to 'llvmc -linker=c++'. I prefer to do things
this way, that's why it's not possible to access argv[0] from
tablegen:-)

-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments


From neelnagar42 at gmail.com  Mon Jun 29 13:30:11 2009
From: neelnagar42 at gmail.com (Neel Nagar)
Date: Mon, 29 Jun 2009 20:30:11 +0000
Subject: [LLVMdev] configuring cross compiler for Mac to Linux on ARM
Message-ID: <503ab6d60906291330i66f83922n82d58d3bd016b28e@mail.gmail.com>

Hello,

I am trying to cross compile LLVM.
Build and compile on Mac OS X 10.5.7
Target is an Angstrom Linux Cortex-A8 Beagle board.
I would like to avoid GPLv3.

I can compile. But when I run my executable on Beagle crt0.S is
calling an AngelSWI to
setup the heap and stack.  But the AngelSWI seems to just be a stub
because it returns zeros for the pointers. That leads to a segfault.

If I hack in a reasonable stack then I can run some simple code. But
it dies if I try to printf() or do anything system related.

I am building binutils, then llvm, then combined.   I have tried many
different combinations of configure options. I have RTFM and RTFS but
am still stumped.  Any help would be greatly appreciated.

Currently using:  ../../combined/configure
--prefix=/Users/neel/llvm/llvm-top/install/onmacosx/arm
--build=i686-apple-darwin9 --host=i686-apple-darwin9 --target=arm-eabi
--with-cpu=cortex-a8 --with-fpu=neon --with-abi=aapcs
--with-float=hard
--enable-llvm=/Users/neel/llvm/llvm-top/build-la/llvm
--program-prefix=llvm- --enable-languages=c,c++ --disable-bootstrap
--with-newlib --with-headers=yes --disable-multilib

Questions:

1) What are the best configure options for building this cross
compiler Mac => ARM Linux?

2) Is newlib recommended for use with Linux and LLVM? I have read posts
saying newlib is obsolete and other posts saying it is critical. Some
posts suggest it is only needed for running on bare metal with no OS?

3) Are the AngelSWIs supported on ARM Linux? They don't seem to do
anything for me when I call them. They may be just stubs.

4) Should I use ARM_RDI_MONITOR or ARM_RDP_MONITOR or nothing on Beagle?

5) I have read lots of conflicting advice on what my target should be.
Should I use "arm-elf" or "arm-eabi" or "arm-angstrom-linux-gnueabi"
or "arm-none-linux-gnueabi" or...?

Here is what I get when I compile a very simple C program using:

    llvm-gcc -v -specs=linux.specs simple.c

Using built-in specs.
Reading specs from
/Users/neel/llvm/llvm-top/install/onmacosx/arm/lib/gcc/arm-eabi/4.2.1/../../../../arm-eabi/lib/linux.specs
rename spec lib to libc
Target: arm-eabi
Configured with: ../../combined/configure
--prefix=/Users/neel/llvm/llvm-top/install/onmacosx/arm
--build=i686-apple-darwin9 --host=i686-apple-darwin9 --target=arm-eabi
--with-cpu=cortex-a8 --with-fpu=neon --with-abi=aapcs
--with-float=hard
--enable-llvm=/Users/neel/llvm/llvm-top/build-la/llvm
--program-prefix=llvm- --enable-languages=c,c++ --disable-bootstrap
--with-newlib --with-headers=yes --disable-multilib
Thread model: single
gcc version 4.2.1 (Based on Apple Inc. build 5646) (LLVM build)
 /Users/neel/llvm/llvm-top/install/onmacosx/arm/libexec/gcc/arm-eabi/4.2.1/cc1
-quiet -v -D__USES_INITFINI__ simple.c -quiet -dumpbase simple.c
-mcpu=cortex-a8 -mfloat-abi=hard -mfpu=neon -mabi=aapcs -auxbase
simple -version -o
/var/folders/0L/0L9UbM9ZEWShfNO8Ptl4sE+++TI/-Tmp-//ccwys5tO.s
ignoring nonexistent directory
"/Users/neel/llvm/llvm-top/install/onmacosx/arm/lib/gcc/arm-eabi/4.2.1/../../../../arm-eabi/sys-include"
#include "..." search starts here:
#include <...> search starts here:
 /Users/neel/llvm/llvm-top/install/onmacosx/arm/lib/gcc/arm-eabi/4.2.1/include
 /Users/neel/llvm/llvm-top/install/onmacosx/arm/lib/gcc/arm-eabi/4.2.1/../../../../arm-eabi/include
End of search list.
GNU C version 4.2.1 (Based on Apple Inc. build 5646) (LLVM build) (arm-eabi)
	compiled by GNU C version 4.0.1 (Apple Inc. build 5490).
GGC heuristics: --param ggc-min-expand=150 --param ggc-min-heapsize=131072
Compiler executable checksum: 91bde4799b0a9c4384e1675516753c28
 /Users/neel/llvm/llvm-top/install/onmacosx/arm/lib/gcc/arm-eabi/4.2.1/../../../../arm-eabi/bin/as
-mcpu=cortex-a8 -mfloat-abi=hard -mfpu=neon -meabi=4 -o
/var/folders/0L/0L9UbM9ZEWShfNO8Ptl4sE+++TI/-Tmp-//ccqpsSXn.o
/var/folders/0L/0L9UbM9ZEWShfNO8Ptl4sE+++TI/-Tmp-//ccwys5tO.s
 /Users/neel/llvm/llvm-top/install/onmacosx/arm/libexec/gcc/arm-eabi/4.2.1/collect2
-X /Users/neel/llvm/llvm-top/install/onmacosx/arm/lib/gcc/arm-eabi/4.2.1/../../../../arm-eabi/lib/linux-crt0.o
/Users/neel/llvm/llvm-top/install/onmacosx/arm/lib/gcc/arm-eabi/4.2.1/crti.o
/Users/neel/llvm/llvm-top/install/onmacosx/arm/lib/gcc/arm-eabi/4.2.1/crtbegin.o
-L/Users/neel/llvm/llvm-top/install/onmacosx/arm/lib/gcc/arm-eabi/4.2.1
-L/Users/neel/llvm/llvm-top/install/onmacosx/arm/lib/gcc/arm-eabi/4.2.1/../../../../arm-eabi/lib
/var/folders/0L/0L9UbM9ZEWShfNO8Ptl4sE+++TI/-Tmp-//ccqpsSXn.o
--start-group -lgcc -lc -lgloss-linux --end-group
/Users/neel/llvm/llvm-top/install/onmacosx/arm/lib/gcc/arm-eabi/4.2.1/crtend.o
/Users/neel/llvm/llvm-top/install/onmacosx/arm/lib/gcc/arm-eabi/4.2.1/crtn.o


Thanks,
Neel


From juanc.martinez.santos at gmail.com  Mon Jun 29 14:09:18 2009
From: juanc.martinez.santos at gmail.com (Juan Carlos Martinez Santos)
Date: Mon, 29 Jun 2009 17:09:18 -0400
Subject: [LLVMdev] Generatin code for an ARM-LINUX machine
Message-ID: <d17b77a40906291409g11dac454pebca2253499df2e1@mail.gmail.com>

I am using the below configuration:

./configure --with-llvmgccdir=/home/jcmartin78/LLVM/llvm-gcc4.2
--prefix=/home/jcmartin78/local --enable-optimized=1 --enable-debug-runtime
--enable-jit --enable-targets=arm --target=arm

When I use LLVMC to compile a simple program I get this:

$ llvmc hello.c
llc: error auto-selecting target for module 'No available targets are
compatible with this module'.  Please use the -march option to explicitly
pick a target.

Using the -march options, I get this:

$ llvmc -march=arm hello.c
hello.c:1: error: bad value (arm) for -march= switch
hello.c:1: error: bad value (arm) for -mtune= switch

Somebody has an idea what is wrong in my procedure? I am using a x86-linux
machine and I want to generate code for an arm-linux machine (also, I am
using the binutils 2.19 to build my cross-compiler).

-- 
Juan Carlos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090629/66a86e24/attachment.html>

From brukman at gmail.com  Mon Jun 29 14:23:36 2009
From: brukman at gmail.com (Misha Brukman)
Date: Mon, 29 Jun 2009 17:23:36 -0400
Subject: [LLVMdev] Generatin code for an ARM-LINUX machine
In-Reply-To: <d17b77a40906291409g11dac454pebca2253499df2e1@mail.gmail.com>
References: <d17b77a40906291409g11dac454pebca2253499df2e1@mail.gmail.com>
Message-ID: <f88b89a50906291423t771f371fnccc1bab77c715155@mail.gmail.com>

I have not used llvmc to build ARM binaries, but llvm-gcc does work.There's
a script to build llvm-gcc x86 -> ARM cross-compiler in
llvm/utils/crosstool/ARM/ .

2009/6/29 Juan Carlos Martinez Santos <juanc.martinez.santos at gmail.com>

> I am using the below configuration:
>
> ./configure --with-llvmgccdir=/home/jcmartin78/LLVM/llvm-gcc4.2
> --prefix=/home/jcmartin78/local --enable-optimized=1 --enable-debug-runtime
> --enable-jit --enable-targets=arm --target=arm
>
> When I use LLVMC to compile a simple program I get this:
>
> $ llvmc hello.c
> llc: error auto-selecting target for module 'No available targets are
> compatible with this module'.  Please use the -march option to explicitly
> pick a target.
>
> Using the -march options, I get this:
>
> $ llvmc -march=arm hello.c
> hello.c:1: error: bad value (arm) for -march= switch
> hello.c:1: error: bad value (arm) for -mtune= switch
>
> Somebody has an idea what is wrong in my procedure? I am using a x86-linux
> machine and I want to generate code for an arm-linux machine (also, I am
> using the binutils 2.19 to build my cross-compiler).
>
> --
> Juan Carlos
>
> _______________________________________________
> 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.llvm.org/pipermail/llvm-dev/attachments/20090629/f832ba2c/attachment.html>

From brukman at gmail.com  Mon Jun 29 14:25:52 2009
From: brukman at gmail.com (Misha Brukman)
Date: Mon, 29 Jun 2009 17:25:52 -0400
Subject: [LLVMdev] CROSS COMPILING LLVM
In-Reply-To: <0A2B3482-1FB2-4934-B16B-92E070BB6351@apple.com>
References: <20090610171705.9A51E606897@ws1-4.us4.outblaze.com>
	<f88b89a50906111918ja679b19o82b66e0980b9cbbf@mail.gmail.com>
	<0A2B3482-1FB2-4934-B16B-92E070BB6351@apple.com>
Message-ID: <f88b89a50906291425g5116b44med3d8760ea4fff36@mail.gmail.com>

2009/6/12 Bob Wilson <bob.wilson at apple.com>

> Thanks, this should be useful.  What problem did you have with svn
> revisions after 70786?


 /tmp/llvm-project.p28262/obj/llvm-gcc-4.2/./gcc/xgcc
-B/tmp/llvm-project.p28262/obj/llvm-gcc-4.2/./gcc/
-B/tmp/llvm-73246/llvm-project/x86_64-unknown-linux-gnu/arm-none-linux-gnueabi/llvm-gcc-4.2/arm-none-linux-gnueabi/bin/
-B/tmp/llvm-73246/llvm-project/x86_64-unknown-linux-gnu/arm-none-linux-gnueabi/llvm-gcc-4.2/arm-none-linux-gnueabi/lib/
-isystem /tmp/llvm-73246/llvm-project/x86_64-unknown-linux-gnu/arm-none-linux-gnueabi/llvm-gcc-4.2/arm-none-linux-gnueabi/include
-isystem /tmp/llvm-73246/llvm-project/x86_64-unknown-linux-gnu/arm-none-linux-gnueabi/llvm-gcc-4.2/arm-none-linux-gnueabi/sys-include
-DHAVE_CONFIG_H -I.
-I/tmp/llvm-project.p28262/src/llvm-gcc-4.2/libmudflap -I. -Wall
-ffunction-sections -fdata-sections -O2 -g -O2 -MT mf-heuristics.lo
-MD -MP -MF .deps/mf-heuristics.Tpo -c
/tmp/llvm-project.p28262/src/llvm-gcc-4.2/libmudflap/mf-heuristics.c
-fPIC -DPIC -o .libs/mf-heuristics.o
cc1: /tmp/llvm-project.p28262/src/llvm/include/llvm/CodeGen/LiveIntervalAnalysis.h:134:
llvm::LiveInterval& llvm::LiveIntervals::getInterval(unsigned int):
Assertion `I != r2iMap_.end() && "Interval does not exist for
register"' failed.
/tmp/llvm-project.p28262/src/llvm-gcc-4.2/libmudflap/mf-heuristics.c:175:
internal compiler error: Aborted
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://llvm.org/bugs/> for instructions.
make[4]: *** [mf-heuristics.lo] Error 1
make[4]: Leaving directory
`/tmp/llvm-project.p28262/obj/llvm-gcc-4.2/arm-none-linux-gnueabi/libmudflap'

I don't have my build tree any longer that has the intermediate object
files, so I'll try to re-create it so I can disect the .bc file to figure
out what's wrong here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090629/32de8cf9/attachment.html>

From david_goodwin at apple.com  Mon Jun 29 14:52:05 2009
From: david_goodwin at apple.com (David Goodwin)
Date: Mon, 29 Jun 2009 14:52:05 -0700
Subject: [LLVMdev] difficulting matching i64 subtract immediate due to isel
	normalization of sub -> add
Message-ID: <6174268B-EBFB-47F5-9D73-AEC9F04094B3@apple.com>

Hi,

For some 64-bit immediates, ARM can generate a two instruction  
sequence. For example, for the following code:

; 734439407618 = 0x000000ab00000002
define i64 @f1(i64 %a) {
     %tmp = sub i64 %a, 734439407618
     ret i64 %tmp
}

We should be able to generate:

	subs r0, r0, #1
	sbc r1, r1, #171   @ 0xab


But instead we get:

$ llvm-as < %s | llc -march=thumb -mattr=+thumb2

	mvn r2, #1
	mvn r3, #171
	adds r0, r0, r2
	adc r1, r1, r3

(mvn is "move not").

We have code selector patterns for sube and subc that do the right  
thing, but they are not used because isel is converting the "sub i64  
a, i" into "add i64 a, -i". This leads to the attached DAG that is  
impossible to write a pattern for because the addc is producing both a  
carry and a register output, and the adde is consuming the carry and  
producing another output.

I suppose I can write code to match this... but is there a better way?

David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dag.tiff
Type: image/tiff
Size: 54108 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090629/8cfc3d53/attachment.tiff>
-------------- next part --------------




From sricketts at maxentric.com  Mon Jun 29 15:41:47 2009
From: sricketts at maxentric.com (Scott Ricketts)
Date: Mon, 29 Jun 2009 15:41:47 -0700
Subject: [LLVMdev]  Type get size
Message-ID: <6d9073030906291541x4a87846ajc63ae7181cdb0108@mail.gmail.com>

I am trying to get the address ranges that are allocated by the global
variable list of a module. I cannot seem to find an easy way to get
the size of a global variable. That is, if the C source looks like:

int a[3];

then printing the description of the type of this global looks like:

[3 x i32]*

Is there some nice way to get "3 words" or "12 bytes" from the above
example? Let's assume I do some "isSized" check. It looks like there
is a getPrimitiveSizeInBits, but nothing for composite types. Maybe I
am missing something.

Thanks,
Scott


From evan.cheng at apple.com  Mon Jun 29 16:48:49 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Mon, 29 Jun 2009 16:48:49 -0700
Subject: [LLVMdev] Using LLVM on an embedded device
In-Reply-To: <ADCE5AA1DF84024C88B9B8A29D9553C6044976FC@mx2.telecom.sna.samsung.com>
References: <06D0EA1E017D5048884831C10A60EA4C071E0A05@mx2.telecom.sna.samsung.com>
	<ADCE5AA1DF84024C88B9B8A29D9553C6044976FB@mx2.telecom.sna.samsung.com>
	<ADCE5AA1DF84024C88B9B8A29D9553C6044976FC@mx2.telecom.sna.samsung.com>
Message-ID: <258D7AE6-03CE-4AC4-97F2-F22A761D4062@apple.com>


On Jun 26, 2009, at 3:11 PM, Anna Zaks wrote:

> Hi Evan,
>
> Sorry for the delayed reply. We've compiled llvm on Linux with only  
> the x86 target, which produced an lli executable that's about 5.5MB.  
> The LLVMX86CodeGen.o alone is 1.7MB. We've configured with
>
> --disable-assertions --enable-optimized --enable-targets=x86 -- 
> disable-debug-runtime --enable-bindings=none --disable-ltdl-install  
> --disable-shared --enable-static
>
> Are there any tips on making them even smaller? It seems that the  
> ARM backend would be smaller but I am not sure if we could get it  
> under 2MB. Also I guess, the interpreter could be removed, but it is  
> quite small (145KB).
>

Size of lli is a poor indicator for dynamic memory footprint. You  
really have to measure in a JIT environment. That said, there are  
definitely possibilities for reducing the size. But I don't think  
there is anyone actively working on it.

Evan
>
> Thank you,
> Anna.
>
>
> > Hi,
> >
> > I am researching a possibility of running LLVM components (such as
> > JIT) on an embedded device, where the memory footprint and RAM usage
> > are the main concerns. So I was wondering if anyone could share
> > their experience with running LLVM on an embedded device. What is
> > the approximate code footprint that we are looking at? For example,
> > on an x86 with a minimum set of optimizations and with only the x86
> > backend, it seems difficult to get the LLVM JIT occupy less than
> > 5MB. Is there any performance and memory usage data available?
>
> That seems too high. I would think it's more in the 2MB range. How did
> you come about that figure? x86 instruction selector itself is quite
> large due to the complex selection patterns. I would expect ARM's
> footprint to be smaller.
>
> There are ways to reduce memory foot print further. But it will
> require someone to drive the effort. One of the (very rough) idea is
> to switch to a table driven instruction selector.
>
> Evan
>
> >
> > Thank you!
> > Anna.
> >
>
>
> _______________________________________________
> 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.llvm.org/pipermail/llvm-dev/attachments/20090629/82b284a5/attachment.html>

From rnk at mit.edu  Mon Jun 29 17:41:39 2009
From: rnk at mit.edu (Reid Kleckner)
Date: Mon, 29 Jun 2009 17:41:39 -0700
Subject: [LLVMdev] JIT allocates global data in function body memory
Message-ID: <9a9942200906291741p366b5c23qa52180bbb071d908@mail.gmail.com>

So I (think I) found a bug in the JIT:
http://llvm.org/bugs/show_bug.cgi?id=4483

Basically, globals used by a function are allocated in the same buffer
as the first code that uses it.  However, when you free the machine
code, you also free the memory holding the global's data.  The address
is still in the GlobalValue map, so any other code using that global
will access freed memory, which will cause problems as soon as you
reallocate that memory for something else.

I tracked down the commit that introduced the bug:
http://llvm.org/viewvc/llvm-project?view=rev&revision=54442

It very nicely explains what it does, but not why it does it, which
I'd like to know before I change it.  I couldn't find the author
(johannes) on IRC so ssen told me to ask LLVMdev about this behavior.
There's even a patch to work around this behavior on Apple ARM
platforms:
http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/ExecutionEngine/JIT/JIT.cpp?view=diff&pathrev=72630&r1=58687&r2=58688

So what should the right long-term behavior be?  It makes sense to me
to use the JITMemoryManager for this so that clients of the JIT can
customize allocation instead of using malloc or new char[].  On the
other hand, that complicates the API and requires a homegrown malloc
implementation in the DefaultMemoryManager.

Reid


From dalej at apple.com  Mon Jun 29 17:50:18 2009
From: dalej at apple.com (Dale Johannesen)
Date: Mon, 29 Jun 2009 17:50:18 -0700
Subject: [LLVMdev] JIT allocates global data in function body memory
In-Reply-To: <9a9942200906291741p366b5c23qa52180bbb071d908@mail.gmail.com>
References: <9a9942200906291741p366b5c23qa52180bbb071d908@mail.gmail.com>
Message-ID: <D188A28D-BA9C-4262-81BE-6CAB4BBCEBF7@apple.com>


On Jun 29, 2009, at 5:41 PMPDT, Reid Kleckner wrote:

> So I (think I) found a bug in the JIT:
> http://llvm.org/bugs/show_bug.cgi?id=4483
>
> Basically, globals used by a function are allocated in the same buffer
> as the first code that uses it.  However, when you free the machine
> code, you also free the memory holding the global's data.  The address
> is still in the GlobalValue map, so any other code using that global
> will access freed memory, which will cause problems as soon as you
> reallocate that memory for something else.
>
> I tracked down the commit that introduced the bug:
> http://llvm.org/viewvc/llvm-project?view=rev&revision=54442
>
> It very nicely explains what it does, but not why it does it, which
> I'd like to know before I change it.  I couldn't find the author
> (johannes) on IRC so ssen told me to ask LLVMdev about this behavior.

That's me (and I'm not on IRC because I like messages to be  
archived).  The reason everything needs to go in the same buffer is  
that we're JITting code on one machine, then sending it to another to  
be executed, and references from one buffer to another won't work in  
that environment.  So that model needs to continue to work.  If you  
want to generalize it so other models work as well, go ahead.

> There's even a patch to work around this behavior on Apple ARM
> platforms:
> http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/ExecutionEngine/JIT/JIT.cpp?view=diff&pathrev=72630&r1=58687&r2=58688
>
> So what should the right long-term behavior be?  It makes sense to me
> to use the JITMemoryManager for this so that clients of the JIT can
> customize allocation instead of using malloc or new char[].  On the
> other hand, that complicates the API and requires a homegrown malloc
> implementation in the DefaultMemoryManager.
>
> Reid
> _______________________________________________
> 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  Mon Jun 29 18:44:06 2009
From: gohman at apple.com (Dan Gohman)
Date: Mon, 29 Jun 2009 18:44:06 -0700
Subject: [LLVMdev] [cfe-dev] Patch for llvm::DepthFirstIterator.h and
	llvm::PostOrderIterator.h
In-Reply-To: <4A487F17.7010901@tu-dresden.de>
References: <4A44BFEC.9050301@tu-dresden.de>
	<6A4C1440-4054-4EE1-A21E-CF6A55AEE8A1@apple.com>
	<4A487F17.7010901@tu-dresden.de>
Message-ID: <67BF3E43-8DE7-48D0-8208-5DD52383C17C@apple.com>


On Jun 29, 2009, at 1:45 AM, Olaf Krzikalla wrote:


> Hi,
>
> I've done all the minor changes you recommended and have attached a  
> new patch including both files again (even if po_iterator didn't  
> change).

Ok, it looks good to me.

> However:
>
> Dan Gohman schrieb:
>
>> The plural of "child" is "children"; please rename this function
>>
>> accordingly.
>>
> Is "childs" just sloppy, is it american english or is it just a  
> misconception of foreigners like me?
> I think I've already seen it somewhere.

Sloppiness seems unlikely here, and it's not specific to American  
English.

Dan



From sricketts at maxentric.com  Mon Jun 29 18:58:09 2009
From: sricketts at maxentric.com (Scott Ricketts)
Date: Mon, 29 Jun 2009 18:58:09 -0700
Subject: [LLVMdev] Type get size
In-Reply-To: <6d9073030906291541x4a87846ajc63ae7181cdb0108@mail.gmail.com>
References: <6d9073030906291541x4a87846ajc63ae7181cdb0108@mail.gmail.com>
Message-ID: <6d9073030906291858u4dad67fay96cd976f8f2a1f70@mail.gmail.com>

Ah, I needed some target-dependent stuff (TargetData) to make this work.

On Mon, Jun 29, 2009 at 3:41 PM, Scott Ricketts<sricketts at maxentric.com> wrote:
> I am trying to get the address ranges that are allocated by the global
> variable list of a module. I cannot seem to find an easy way to get
> the size of a global variable.

I used TargetData::getTypeSizeInBits(const Type* Ty). Also, I added:

AU.addRequired<TargetData>();

to getAnalysisUsage(AnalysisUsage &AU) for my pass struct.

There are a few other options for getting type size from TargetData
(e.g. getTypeAllocSize).

Scott


From the.dead.shall.rise at gmail.com  Mon Jun 29 19:02:45 2009
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Tue, 30 Jun 2009 04:02:45 +0200
Subject: [LLVMdev] llvmc for PIC16
In-Reply-To: <4A48ED9A.2040403@microchip.com>
References: <4A2633E9.4070207@microchip.com> <4A28C062.9060307@microchip.com>
	<loom.20090607T070933-452@post.gmane.org>
	<4A35EA76.7090602@microchip.com>
	<3cb898890906150348l2e0d4095seb54de38f95e69f9@mail.gmail.com>
	<4A3656A3.1050403@microchip.com>
	<3cb898890906150730k534167dfxf59677e966477220@mail.gmail.com>
	<4A39F1D7.4060101@microchip.com>
	<3cb898890906180430k5cb0d57fh7c66d10a45c50db0@mail.gmail.com>
	<4A48ED9A.2040403@microchip.com>
Message-ID: <3cb898890906291902t1e965aa9h6df1f325684b5f47@mail.gmail.com>

Hi Sanjiv,

2009/6/29 Sanjiv Gupta <sanjiv.gupta at microchip.com>:
> I want to retrieve the value of argv[0] (which was passed to main function
> of the driver) in PrependCustomizedPath.

I've added a way to access argv[0] in hooks:
http://thread.gmane.org/gmane.comp.compilers.llvm.cvs/50789


-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments


From rnk at mit.edu  Mon Jun 29 19:23:38 2009
From: rnk at mit.edu (Reid Kleckner)
Date: Mon, 29 Jun 2009 19:23:38 -0700
Subject: [LLVMdev] JIT allocates global data in function body memory
In-Reply-To: <D188A28D-BA9C-4262-81BE-6CAB4BBCEBF7@apple.com>
References: <9a9942200906291741p366b5c23qa52180bbb071d908@mail.gmail.com> 
	<D188A28D-BA9C-4262-81BE-6CAB4BBCEBF7@apple.com>
Message-ID: <9a9942200906291923hb74da39ra522f5b4cfbdf2@mail.gmail.com>

> That's me (and I'm not on IRC because I like messages to be
> archived).  The reason everything needs to go in the same buffer is
> that we're JITting code on one machine, then sending it to another to
> be executed, and references from one buffer to another won't work in
> that environment.  So that model needs to continue to work.  If you
> want to generalize it so other models work as well, go ahead.

Maybe what I should do then is change
TargetJITInfo::allocateSeparateGVMemory to allocateGVsWithCode and
invert the meaning, since I feel like most users probably just want
malloc or something similar.  You could then subclass the appropriate
TJI class and override that method.  Would that be a reasonable API
change?  No one else calls or overrides that method.  In order to do
that we'd also need to hear from Evan about why Apple ARM needs to use
malloc.

Is it worth allocating global data through the memory manager, or is
better to use malloc?  Currently global data lives forever (or rather,
as long as the JIT does, which makes sense since they live forever in
a statically compiled program), so I was thinking it might be good for
memory usage and locality to put small globals together into a buffer
similar to the function stub buffer.  That way you don't call malloc
for every global int64, and you can lay them out sequentially in
memory.  Large global arrays should probably get their own block.

Reid



From linus_wind at zju.edu.cn  Mon Jun 29 19:32:33 2009
From: linus_wind at zju.edu.cn (Wenzhi Tao)
Date: Tue, 30 Jun 2009 10:32:33 +0800
Subject: [LLVMdev] Limitations of Alias Analysis?
In-Reply-To: <4A487D27.4040201@free.fr>
References: <446261587.07109@zju.edu.cn>  <4A487D27.4040201@free.fr>
Message-ID: <446327340.24553@zju.edu.cn>

Hi Duncan,
  I tried to perform alias analysis after optimization(O1, since O2 and
O3 implement inlining).

  opt -O1 test.bc -o o1.bc

  The content of main() is listed as follow:
define i32 @main() nounwind {
entry:
	%0 = tail call %struct.Location* @getNewLocation(i32 0, i32 0)
nounwind		; <%struct.Location*> [#uses=2]
	%1 = tail call %struct.Location* @getNewLocation(i32 1, i32 2)
nounwind		; <%struct.Location*> [#uses=2]
	%2 = tail call %struct.Location* @sub(%struct.Location* %0, %
struct.Location* %1) nounwind		; <%struct.Location*> [#uses=1]
	%3 = bitcast %struct.Location* %0 to i8*		; <i8*> [#uses=1]
	tail call void @free(i8* %3) nounwind
	%4 = bitcast %struct.Location* %1 to i8*		; <i8*> [#uses=1]
	tail call void @free(i8* %4) nounwind
	%5 = bitcast %struct.Location* %2 to i8*		; <i8*> [#uses=1]
	tail call void @free(i8* %5) nounwind
	ret i32 0
}

  Then, the AA result with option "-basicaa -ds-aa -anders-aa" is:

  MayAlias:	%struct.Location* %0, %struct.Location* %1
  MayAlias:	%struct.Location* %0, %struct.Location* %2
  MayAlias:	%struct.Location* %1, %struct.Location* %2

  %0 and %1 are still considered as 'may alias'.

在 2009-06-29一的 10:36 +0200，Duncan Sands写道：
> Hi,
> 
> > llvm-gcc -emit-llvm -O0 -c test.c -o test.bc
> 
> try compiling with optimization.
> 
> Ciao,
> 
> Duncan.
> 



From sanjiv.gupta at microchip.com  Mon Jun 29 19:37:36 2009
From: sanjiv.gupta at microchip.com (Sanjiv Gupta)
Date: Tue, 30 Jun 2009 08:07:36 +0530
Subject: [LLVMdev] llvmc for PIC16
In-Reply-To: <3cb898890906291902t1e965aa9h6df1f325684b5f47@mail.gmail.com>
References: <4A2633E9.4070207@microchip.com> <4A28C062.9060307@microchip.com>	
	<loom.20090607T070933-452@post.gmane.org>	
	<4A35EA76.7090602@microchip.com>	
	<3cb898890906150348l2e0d4095seb54de38f95e69f9@mail.gmail.com>	
	<4A3656A3.1050403@microchip.com>	
	<3cb898890906150730k534167dfxf59677e966477220@mail.gmail.com>	
	<4A39F1D7.4060101@microchip.com>	
	<3cb898890906180430k5cb0d57fh7c66d10a45c50db0@mail.gmail.com>	
	<4A48ED9A.2040403@microchip.com>
	<3cb898890906291902t1e965aa9h6df1f325684b5f47@mail.gmail.com>
Message-ID: <4A497A70.6020207@microchip.com>

Mikhail Glushenkov wrote:
> Hi Sanjiv,
>
> 2009/6/29 Sanjiv Gupta <sanjiv.gupta at microchip.com>:
>   
>> I want to retrieve the value of argv[0] (which was passed to main function
>> of the driver) in PrependCustomizedPath.
>>     
>
> I've added a way to access argv[0] in hooks:
> http://thread.gmane.org/gmane.comp.compilers.llvm.cvs/50789
>
>
>   
Thanks for that. My purpose is not to depend upon the "executable name".
I wanted to be able to retrieve the absolute path from where the 
executable was picked as that location will contain other stuff (libs 
and header files) which I need to pass to the tools that driver 
executes. Your changes will serve the purpose.

Thanks,
Sanjiv


From sanjiv.gupta at microchip.com  Mon Jun 29 19:40:57 2009
From: sanjiv.gupta at microchip.com (Sanjiv Gupta)
Date: Tue, 30 Jun 2009 08:10:57 +0530
Subject: [LLVMdev] llvmc for PIC16
In-Reply-To: <3cb898890906291902t1e965aa9h6df1f325684b5f47@mail.gmail.com>
References: <4A2633E9.4070207@microchip.com> <4A28C062.9060307@microchip.com>	
	<loom.20090607T070933-452@post.gmane.org>	
	<4A35EA76.7090602@microchip.com>	
	<3cb898890906150348l2e0d4095seb54de38f95e69f9@mail.gmail.com>	
	<4A3656A3.1050403@microchip.com>	
	<3cb898890906150730k534167dfxf59677e966477220@mail.gmail.com>	
	<4A39F1D7.4060101@microchip.com>	
	<3cb898890906180430k5cb0d57fh7c66d10a45c50db0@mail.gmail.com>	
	<4A48ED9A.2040403@microchip.com>
	<3cb898890906291902t1e965aa9h6df1f325684b5f47@mail.gmail.com>
Message-ID: <4A497B39.1010709@microchip.com>

Mikhail Glushenkov wrote:
> Hi Sanjiv,
>
> 2009/6/29 Sanjiv Gupta <sanjiv.gupta at microchip.com>:
>   
>> I want to retrieve the value of argv[0] (which was passed to main function
>> of the driver) in PrependCustomizedPath.
>>     
>
> I've added a way to access argv[0] in hooks:
> http://thread.gmane.org/gmane.comp.compilers.llvm.cvs/50789
>
>
>   
One more thing:
How to make --save-temps always on, so that users won't have to specify 
it every time they invoke the driver?

- Sanjiv


From linus_wind at zju.edu.cn  Mon Jun 29 19:40:53 2009
From: linus_wind at zju.edu.cn (Wenzhi Tao)
Date: Tue, 30 Jun 2009 10:40:53 +0800
Subject: [LLVMdev] Limitations of Alias Analysis?
In-Reply-To: <4A487FF4.9060007@gmail.com>
References: <446261587.07109@zju.edu.cn>  <4A487FF4.9060007@gmail.com>
Message-ID: <446327839.30312@zju.edu.cn>

Hi,
  Thanks for your advice. I have tried this way:

  opt -mem2reg test.bc -o mem2reg.bc
  llvm-dis mem2reg.bc
  opt -functionattrs -basicaa -aa-eval -print-all-alias-modref-info
mem2reg.bc

  The content of main() in mem2reg.ll:

define i32 @main() nounwind {
entry:
	%"alloca point" = bitcast i32 0 to i32		; <i32> [#uses=0]
	%0 = call %struct.Location* @getNewLocation(i32 0, i32 0) nounwind		; <
%struct.Location*> [#uses=2]
	%1 = call %struct.Location* @getNewLocation(i32 1, i32 2) nounwind		; <
%struct.Location*> [#uses=2]
	%2 = call %struct.Location* @sub(%struct.Location* %0, %
struct.Location* %1) nounwind		; <%struct.Location*> [#uses=1]
	%3 = bitcast %struct.Location* %0 to i8*		; <i8*> [#uses=1]
	call void @free(i8* %3) nounwind
	%4 = bitcast %struct.Location* %1 to i8*		; <i8*> [#uses=1]
	call void @free(i8* %4) nounwind
	%5 = bitcast %struct.Location* %2 to i8*		; <i8*> [#uses=1]
	call void @free(i8* %5) nounwind
	br label %return

return:		; preds = %entry
	ret i32 0
}

   The result of -aa-eval:

  MayAlias:	%struct.Location* %0, %struct.Location* %1
  MayAlias:	%struct.Location* %0, %struct.Location* %2
  MayAlias:	%struct.Location* %1, %struct.Location* %2

   Even when I add the AA option "-ds-aa -anders-aa", the result keeps
unchanged. en, I don't know if I miss some steps or the method doesn't
work at all.

在 2009-06-29一的 11:48 +0300，Török Edwin写道：
> On 2009-06-29 11:16, Wenzhi Tao wrote:
> > Hi, all
> >
> >   According to the document "LLVM Alias Analysis Infrastructure", I
> > evaluated the AA performance by using the paramenters '-basicaa -ds-aa
> > -anders-aa'. The source code 'test.c' is listed as follow:
> > [...] 
> > The whole process:
> >
> > llvm-gcc -emit-llvm -O0 -c test.c -o test.bc
> >
> > opt test.bc -load libLLVMDataStructure.so -basic-aa -ds-aa -anders-aa
> > -aa-eval -print-all-alias-modref-info
> >   
> 
> Try this:
> opt -mem2reg -functionattrs -basic-aa -aa-eval
> -print-all-alias-modref-info test.bc
> 
> It shows:
>   NoAlias:      %struct.Location* %0, %struct.Location* %1
> 
> > %1 and %2 are considered as MayAlias results that while using
> > llvm::MemoryDependenceAnalysis, %2 is dependent on %1(clobber). But in
> > fact it's not.
> >
> > Maybe a flow-sensitive, context-sensitive alias analysis algorithm is
> > needed to generate more precise result? Correct me, if I'm wrong. Thank
> > you.
> >   
> 
> Running the functionattrs pass should be enough to add the 'noalias'
> marker on getNewLocation(), and then even basic-aa can see that loc1 and
> loc2 are NoAlias.
> You also need to run -mem2reg, because otherwise -functionattrs doesn't
> see that the return value is coming from a malloc (which already has
> noalias attribute).
> 
> Best regards,
> --Edwin
> 
> 



From the.dead.shall.rise at gmail.com  Mon Jun 29 19:50:58 2009
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Tue, 30 Jun 2009 04:50:58 +0200
Subject: [LLVMdev] llvmc for PIC16
In-Reply-To: <4A497B39.1010709@microchip.com>
References: <4A2633E9.4070207@microchip.com> <4A35EA76.7090602@microchip.com>
	<3cb898890906150348l2e0d4095seb54de38f95e69f9@mail.gmail.com>
	<4A3656A3.1050403@microchip.com>
	<3cb898890906150730k534167dfxf59677e966477220@mail.gmail.com>
	<4A39F1D7.4060101@microchip.com>
	<3cb898890906180430k5cb0d57fh7c66d10a45c50db0@mail.gmail.com>
	<4A48ED9A.2040403@microchip.com>
	<3cb898890906291902t1e965aa9h6df1f325684b5f47@mail.gmail.com>
	<4A497B39.1010709@microchip.com>
Message-ID: <3cb898890906291950t4e670f35w953103e7080a62e6@mail.gmail.com>

Hi Sanjiv,

2009/6/30 Sanjiv Gupta <sanjiv.gupta at microchip.com>:
> One more thing:
> How to make --save-temps always on, so that users won't have to specify it
> every time they invoke the driver?

Either always run the driver via an alias, or edit
lib/CompilerDriver/BuiltinOptions.cpp:

cl::opt<SaveTempsEnum::Values> SaveTemps
("save-temps", cl::desc("Keep temporary files"),
 cl::init(SaveTempsEnum::Unset), // <- Change Unset to Cwd


-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments


From eli.friedman at gmail.com  Mon Jun 29 20:35:46 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Mon, 29 Jun 2009 20:35:46 -0700
Subject: [LLVMdev] Limitations of Alias Analysis?
In-Reply-To: <446327839.30312@zju.edu.cn>
References: <446261587.07109@zju.edu.cn> <4A487FF4.9060007@gmail.com>
	<446327839.30312@zju.edu.cn>
Message-ID: <f5aa3e9b0906292035x5493322bk652870eff21e660b@mail.gmail.com>

On Mon, Jun 29, 2009 at 7:40 PM, Wenzhi Tao<linus_wind at zju.edu.cn> wrote:
>   The result of -aa-eval:
>
>  MayAlias:     %struct.Location* %0, %struct.Location* %1
>  MayAlias:     %struct.Location* %0, %struct.Location* %2
>  MayAlias:     %struct.Location* %1, %struct.Location* %2

I'm getting NoAlias with the given steps; are you using trunk LLVM?

-Eli



From clattner at apple.com  Mon Jun 29 21:23:43 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 29 Jun 2009 21:23:43 -0700
Subject: [LLVMdev] difficulting matching i64 subtract immediate due to
	isel normalization of sub -> add
In-Reply-To: <6174268B-EBFB-47F5-9D73-AEC9F04094B3@apple.com>
References: <6174268B-EBFB-47F5-9D73-AEC9F04094B3@apple.com>
Message-ID: <9CD93EF1-4847-4C36-AAD7-9DA743B444A8@apple.com>


On Jun 29, 2009, at 2:52 PM, David Goodwin wrote:

> Hi,
>
> For some 64-bit immediates, ARM can generate a two instruction  
> sequence. For example, for the following code:
>
>
> We have code selector patterns for sube and subc that do the right  
> thing, but they are not used because isel is converting the "sub i64  
> a, i" into "add i64 a, -i". This leads to the attached DAG that is  
> impossible to write a pattern for because the addc is producing both  
> a carry and a register output, and the adde is consuming the carry  
> and producing another output.
>
> I suppose I can write code to match this... but is there a better way?

You can write a custom expander for legalizetypes of "add i64" that  
would handle this case and fall through to the normal legalize code in  
other cases.

-Chris


From clattner at apple.com  Mon Jun 29 21:46:47 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 29 Jun 2009 21:46:47 -0700
Subject: [LLVMdev] Pinning registers in LLVM
In-Reply-To: <F8C491D7-1C02-4C61-B690-1D62346EA9F6@gmail.com>
References: <F8C491D7-1C02-4C61-B690-1D62346EA9F6@gmail.com>
Message-ID: <BC3393FA-BA57-4D35-ADB4-CEEAA2740820@apple.com>


On Jun 28, 2009, at 11:00 PM, David Terei wrote:

> Hi all,
>
> I'm working on using LLVM as a back-end for an existing compiler (GHC
> Haskell compiler)

Very cool!

> and one of the problems I'm having is pinning a
> global variable to a actual machine register. I've seen mixed
> terminology for this feature/idea, so what I mean by this is that I
> want to be able to put a global variable into a specified hardware
> register.

Lets separate two things here: 1) GCC's implementation of this feature  
2) the semantic/perf effect of doing it.

For 1) GCC implements this feature (with the example code you gave) by  
globally changing the allocatable register set for the backend and  
pinning the value to the specified physical register.  This is really  
easy for GCC to do (yay, global variables for everyone, even the  
backend) and has the "right effect".  However, this implementation is  
inappropriate in LLVM: if we wanted to take this approach, we'd have  
to encode the set of pinned physregs in the top-level module structure  
somewhere: this is not impossible, but it is kinda ugly.

#2 is the more interesting part of this.  Ignoring GCC's  
implementation of this, the semantic effect of this is that the  
calling convention of the functions in the translation unit are  
changed (so that the global is guaranteed to be in the specific  
physreg on entrance/exit of the function) and the global is guaranteed  
to be in the register in inline asms.  Interestingly (to me at  
least :), there is no guarantee that this value be in the physreg at a  
random point in the function.  There is no "defined" way to notice  
this, so the compiler can cheat and reuse the register if it wants to  
(e.g. spilling the temp value to the stack etc).  While you could  
notice this with a debugger, performance tool, etc, normal code should  
be fine.

> This declaration should thus reserve that machine register
> for exclusive use by this global variable. This is used in GHC since
> it defines an abstract machine as part of its execution model, with
> this abstract machine consisting of several virtual registers. Due to
> the frequency the virtual registers are accessed it is best for
> performance that they be permanently assigned to a physical machine
> register.

Right.  Coming back to "why do this", you want it because it is good  
for performance: these values are accessed frequently enough that  
going to globals (particularly for PIC code) is too expensive.

> A very simple example C program using this feature:
>
> --------------------------
> #include <stdio.h>
>
> register int R1 __asm__ ("esi");
>
> int main(void)
> {
> 	R1 = 3;
> 	printf("register: %d\n", R1);
> 	R1 *= 2;
> 	printf("register: %d\n", R1);
> 	return 0;
> }
> --------------------------
>
> llvm-gcc doesn't compile this program correctly, although according to
> the llvm-gcc release notes this extension was first supported by llvm-
> gcc in 1.9.

This program actually works for me if you build with -O, but it looks  
like it is an accident that it works :).  The implementation in llvm- 
gcc could definitely be fixed in this case.  However, the more  
interesting example wouldn't work: if printf were some other function  
and you read ESI in it.

If it were important to me to implement this, I'd implement this  
extension by adding a new custom calling convention to the X86 backend  
that always passed the first i32 value in ESI and always returned the  
first i32 value in ESI.  Given that, you could lower the above code to  
something like this pseudo code:

{i32,i32} @main(i32 %in_esi) {
   %esi = alloca i32
   store in_esi -> esi

   store 3 -> esi

   esi1 = load esi
   {esi2, dead} = call @printf(esi1, "register: %d\n", esi1);
   store esi2 -> esi

   esi3 = load esi
   esi4 = esi3*2
   store esi4 -> esi

   esi5 = load esi
   {esi6, dead} = call @printf(esi5, "register: %d\n", esi5);
   store esi6 -> esi

   esi7 = load esi
   ret {esi7, 0}
}

Each of printf and main would be marked with the custom CC.  After  
running mem2reg on this, you'd get:

{i32,i32} @main(i32 %in_esi) {
   {esi2, dead} = call @printf(3, "register: %d\n", 3);
   esi4 = esi2*2
   {esi6, dead} = call @printf(esi4, "register: %d\n", esi4);
   ret {esi6, 0}
}

When lowered at codegen time, the regalloc would trivially eliminate  
the copies into/out-of ESI and you'd get the code you desired.

No, I don't know of anyone planning to implement this, but it is  
conceptually quite simple :)

-Chris



From sanjiv.gupta at microchip.com  Mon Jun 29 22:14:07 2009
From: sanjiv.gupta at microchip.com (Sanjiv Gupta)
Date: Tue, 30 Jun 2009 10:44:07 +0530
Subject: [LLVMdev] Problems with "module asm"
Message-ID: <4A499F1F.2070900@microchip.com>

This is what the document says:

Module-Level Inline Assembly

Modules may contain "module-level inline asm" blocks, which corresponds 
to the GCC "file scope inline asm" blocks. These blocks are internally 
concatenated by LLVM and treated as a single unit, but may be separated 
in the .ll file if desired. The syntax is very simple:

module asm "inline asm code goes here"
module asm "more can go here"

The strings can contain any character by escaping non-printable 
characters. The escape sequence used is simply "\xx" where "xx" is the 
two digit hex code for the number.

The inline asm code is simply printed to the machine code .s file when 
assembly code is generated.


Here are the problems:

1.  clang-cc needs parentheses or else gives errors. So the actual 
syntax is
     module asm (" blah ");

2. clang-cc gives warnings like
i00202 at ubuntu:/tmp$ cat test.c
module asm ("hello");
module asm ("world");
int main (void) {
}

i00202 at ubuntu:/tmp$ clang-cc -emit-llvm test.c
test.c:1:1: warning: type specifier missing, defaults to 'int'
module asm ("hello");
^
test.c:2:1: warning: type specifier missing, defaults to 'int'
module asm ("world");
^
2 diagnostics generated.

3. The blocks are NOT being concatenated.  Below is the generated .ll file.
i00202 at ubuntu:/tmp$ cat test.ll
; ModuleID = 'test.c'
target datalayout = 
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
target triple = "i386-pc-linux-gnu"
@"\01world" = common global i32 0, align 4        ; <i32*> [#uses=0]

define i32 @main() nounwind {
entry:
    %retval = alloca i32        ; <i32*> [#uses=1]
    %0 = load i32* %retval        ; <i32> [#uses=1]
    ret i32 %0
}


module asm ("hello") is misssing.





From xykong at yahoo.com  Mon Jun 29 22:22:25 2009
From: xykong at yahoo.com (Xiangyun Kong)
Date: Mon, 29 Jun 2009 22:22:25 -0700 (PDT)
Subject: [LLVMdev] About using ParseCommandLine
Message-ID: <527977.10103.qm@web82106.mail.mud.yahoo.com>


I need to use LLVM's command line utilities for parsing command line
in an online compiling mode. Since multiple program may be compiled online
with same or different command line options, the options states need to
be saved and restored.

I found it is hard to save and restore 
opt (options), given that opt are defined with 
C++ templates, and options are registered implicitly through
class constructor.

Not sure if anyone else got the same problems. It will be nice to
add some infrastructural changes to Opt/Option so that the states of
Opt/Option can be saved and restored in a central place.

Any comments or suggestions ?

Thanks.

Xiangyun







From eli.friedman at gmail.com  Mon Jun 29 22:31:59 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Mon, 29 Jun 2009 22:31:59 -0700
Subject: [LLVMdev] Problems with "module asm"
In-Reply-To: <4A499F1F.2070900@microchip.com>
References: <4A499F1F.2070900@microchip.com>
Message-ID: <f5aa3e9b0906292231i3d046b2ei82b5ae75c6ebaef0@mail.gmail.com>

On Mon, Jun 29, 2009 at 10:14 PM, Sanjiv
Gupta<sanjiv.gupta at microchip.com> wrote:
> 1.  clang-cc needs parentheses or else gives errors. So the actual
> syntax is
>     module asm (" blah ");

That declares a variable of type int whose name in the assembly is "
blah "; not what you want.  The correct C syntax is just the
following:
asm(" blah ");

-Eli



From carter_cheng at yahoo.com  Mon Jun 29 23:04:17 2009
From: carter_cheng at yahoo.com (Carter Cheng)
Date: Mon, 29 Jun 2009 23:04:17 -0700 (PDT)
Subject: [LLVMdev] JIT question about resolving unknown function calls
In-Reply-To: <9A3A0323-234A-4B20-BBE9-F1DC8FA608BE@apple.com>
Message-ID: <199759.91232.qm@web50112.mail.re2.yahoo.com>


Thanks.

--- On Mon, 6/29/09, Chris Lattner <clattner at apple.com> wrote:

> From: Chris Lattner <clattner at apple.com>
> Subject: Re: [LLVMdev] JIT question about resolving unknown function calls
> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
> Date: Monday, June 29, 2009, 10:18 AM
> 
> On Jun 29, 2009, at 3:37 AM, Carter Cheng wrote:
> 
> >
> > My understanding is that the JIT system allows during
> the running of  
> > the system resolution of call instructions to
> undefined functions to  
> > be trapped and then patched with the correct address
> (is this true?).
> 
> Yes, see:
> http://llvm.org/docs/tutorial/LangImpl4.html#jit
> 
> > The question I have is does the current system also
> allow for  
> > repatching? for a certain OO system I am working on
> this could be  
> > desirable when an object/class is updated and
> replaced- making it  
> > possible in certain cases to update the call point as
> the code is  
> > replaced.
> 
> You can repatch a function that was hitted with the  
> ExecutionEngine::recompileAndRelinkFunction method. 
> If you have a  
> symbol that isn't JIT'd that you want to move around, just
> define a  
> global that holds the pointer, and change the pointer as
> you wish.
> 
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu 
>        http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 


      



From carter_cheng at yahoo.com  Mon Jun 29 23:09:24 2009
From: carter_cheng at yahoo.com (Carter Cheng)
Date: Mon, 29 Jun 2009 23:09:24 -0700 (PDT)
Subject: [LLVMdev] simulating c style unions in LLVM
Message-ID: <245185.53782.qm@web50110.mail.re2.yahoo.com>


I am trying to create a boxed tagged datatype for a language where it is necessary to resolve the type at runtime. If I were writing an interpreter in C- it would most likely look something like this-

struct
{
    unsigned tag;
    union { long Int; double Float; .... }
}

Is there a standard way for constructing a type like this in LLVM?

Thanks again.


      


From eli.friedman at gmail.com  Mon Jun 29 23:20:48 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Mon, 29 Jun 2009 23:20:48 -0700
Subject: [LLVMdev] simulating c style unions in LLVM
In-Reply-To: <245185.53782.qm@web50110.mail.re2.yahoo.com>
References: <245185.53782.qm@web50110.mail.re2.yahoo.com>
Message-ID: <f5aa3e9b0906292320u52f255e2g4dab5a44b354c0d5@mail.gmail.com>

On Mon, Jun 29, 2009 at 11:09 PM, Carter Cheng<carter_cheng at yahoo.com> wrote:
>
> I am trying to create a boxed tagged datatype for a language where it is necessary to resolve the type at runtime. If I were writing an interpreter in C- it would most likely look something like this-
>
> struct
> {
>    unsigned tag;
>    union { long Int; double Float; .... }
> }
>
> Is there a standard way for constructing a type like this in LLVM?

You have to write it using bitcasts.  Try looking at llvm-gcc or clang
output for a rough outline.

-Eli



From me22.ca at gmail.com  Mon Jun 29 23:32:51 2009
From: me22.ca at gmail.com (me22)
Date: Mon, 29 Jun 2009 23:32:51 -0700
Subject: [LLVMdev] simulating c style unions in LLVM
In-Reply-To: <245185.53782.qm@web50110.mail.re2.yahoo.com>
References: <245185.53782.qm@web50110.mail.re2.yahoo.com>
Message-ID: <fa28b9250906292332w3d001f3bvf4ddf713f4a1d8e5@mail.gmail.com>

2009/6/29 Carter Cheng <carter_cheng at yahoo.com>:
>
> I am trying to create a boxed tagged datatype for a language where it is necessary to resolve the type at runtime. If I were writing an interpreter in C- it would most likely look something like this-
>
> Is there a standard way for constructing a type like this in LLVM?
>

Well, you can always ask bitter melon, who translates this:

struct foo
{
   unsigned tag;
   union { long Int; double Float; } data;
};

void bar(struct foo *x) {
    x->data.Int = x->tag;
}

into this:

	%struct.anon = type { double }
	%struct.foo = type { i32, %struct.anon }

define void @bar(%struct.foo* nocapture %x) nounwind {
entry:
	%0 = getelementptr %struct.foo* %x, i32 0, i32 0		; <i32*> [#uses=1]
	%1 = load i32* %0, align 4		; <i32> [#uses=1]
	%2 = getelementptr %struct.foo* %x, i32 0, i32 1		; <%struct.anon*> [#uses=1]
	%3 = bitcast %struct.anon* %2 to i32*		; <i32*> [#uses=1]
	store i32 %1, i32* %3, align 4
	ret void
}

So essentially the union just turns into bitcasts.

I know there was some discussion about adding a first-order union to
LLVM a bit back, but IIRC disagreement over semantics prevented it
from going anywhere.


From carter_cheng at yahoo.com  Tue Jun 30 00:16:01 2009
From: carter_cheng at yahoo.com (Carter Cheng)
Date: Tue, 30 Jun 2009 00:16:01 -0700 (PDT)
Subject: [LLVMdev] simulating c style unions in LLVM
In-Reply-To: <fa28b9250906292332w3d001f3bvf4ddf713f4a1d8e5@mail.gmail.com>
Message-ID: <934057.15557.qm@web50109.mail.re2.yahoo.com>


Thanks both. I looked over the getelementptr and bitcast documentation but I am still a bit confused by one point. lets say i have something like this.

union
{
    long Int; double float; long* IntRef;
}

Since pointer sizes are platform dependent if I am trying to use the union in question with an extern C function is it possible to make write the single definition in a platform independent way?

Thanks in advance.


--- On Mon, 6/29/09, me22 <me22.ca at gmail.com> wrote:

> From: me22 <me22.ca at gmail.com>
> Subject: Re: [LLVMdev] simulating c style unions in LLVM
> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
> Date: Monday, June 29, 2009, 11:32 PM
> 2009/6/29 Carter Cheng <carter_cheng at yahoo.com>:
> >
> > I am trying to create a boxed tagged datatype for a
> language where it is necessary to resolve the type at
> runtime. If I were writing an interpreter in C- it would
> most likely look something like this-
> >
> > Is there a standard way for constructing a type like
> this in LLVM?
> >
> 
> Well, you can always ask bitter melon, who translates
> this:
> 
> struct foo
> {
>    unsigned tag;
>    union { long Int; double Float; } data;
> };
> 
> void bar(struct foo *x) {
>     x->data.Int = x->tag;
> }
> 
> into this:
> 
>     %struct.anon = type { double }
>     %struct.foo = type { i32, %struct.anon
> }
> 
> define void @bar(%struct.foo* nocapture %x) nounwind {
> entry:
>     %0 = getelementptr %struct.foo* %x, i32
> 0, i32 0        ; <i32*>
> [#uses=1]
>     %1 = load i32* %0, align
> 4        ; <i32>
> [#uses=1]
>     %2 = getelementptr %struct.foo* %x, i32
> 0, i32 1        ;
> <%struct.anon*> [#uses=1]
>     %3 = bitcast %struct.anon* %2 to
> i32*        ; <i32*>
> [#uses=1]
>     store i32 %1, i32* %3, align 4
>     ret void
> }
> 
> So essentially the union just turns into bitcasts.
> 
> I know there was some discussion about adding a first-order
> union to
> LLVM a bit back, but IIRC disagreement over semantics
> prevented it
> from going anywhere.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu 
>        http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 


      



From eli.friedman at gmail.com  Tue Jun 30 01:14:13 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Tue, 30 Jun 2009 01:14:13 -0700
Subject: [LLVMdev] simulating c style unions in LLVM
In-Reply-To: <934057.15557.qm@web50109.mail.re2.yahoo.com>
References: <fa28b9250906292332w3d001f3bvf4ddf713f4a1d8e5@mail.gmail.com>
	<934057.15557.qm@web50109.mail.re2.yahoo.com>
Message-ID: <f5aa3e9b0906300114v3bb553a9j7d51ee086b96ed57@mail.gmail.com>

On Tue, Jun 30, 2009 at 12:16 AM, Carter Cheng<carter_cheng at yahoo.com> wrote:
> Since pointer sizes are platform dependent if I am trying to use the union in question with an extern C function is it possible to make write the single definition in a platform independent way?

Not really; there's some discussion of that in the thread starting at
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-May/022132.html .

-Eli


From viridia at gmail.com  Tue Jun 30 01:41:32 2009
From: viridia at gmail.com (Talin)
Date: Tue, 30 Jun 2009 01:41:32 -0700
Subject: [LLVMdev] simulating c style unions in LLVM
In-Reply-To: <f5aa3e9b0906300114v3bb553a9j7d51ee086b96ed57@mail.gmail.com>
References: <fa28b9250906292332w3d001f3bvf4ddf713f4a1d8e5@mail.gmail.com>	<934057.15557.qm@web50109.mail.re2.yahoo.com>
	<f5aa3e9b0906300114v3bb553a9j7d51ee086b96ed57@mail.gmail.com>
Message-ID: <4A49CFBC.9040801@gmail.com>

Eli Friedman wrote:
> On Tue, Jun 30, 2009 at 12:16 AM, Carter Cheng<carter_cheng at yahoo.com> wrote:
>   
>> Since pointer sizes are platform dependent if I am trying to use the union in question with an extern C function is it possible to make write the single definition in a platform independent way?
>>     
>
> Not really; there's some discussion of that in the thread starting at
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-May/022132.html .
>   
And it is something I still want to pursue, but last time I was unable 
to get a consensus on the implementation approach, so I put it off and 
worked on other things in the mean time.

As far as the behavior and syntax, I think that's mostly settled - Chris 
suggested the struct syntax with a 'u' prefix, and I am fine with that.

-- Talin


From Olaf.Krzikalla at tu-dresden.de  Tue Jun 30 03:58:50 2009
From: Olaf.Krzikalla at tu-dresden.de (Olaf Krzikalla)
Date: Tue, 30 Jun 2009 12:58:50 +0200
Subject: [LLVMdev] Urgent fix for MSVC
Message-ID: <4A49EFEA.1040509@tu-dresden.de>

See the patch and the documentation:

http://msdn.microsoft.com/en-us/library/ms686818(VS.85).aspx

With the patch all compiles fine. Otherwise MSVC breaks rightly.

Best
Olaf Krzikalla
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: assertfix.patch
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090630/a3336345/attachment.ksh>

From anton at korobeynikov.info  Tue Jun 30 04:16:20 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Tue, 30 Jun 2009 15:16:20 +0400
Subject: [LLVMdev] Problems with "module asm"
In-Reply-To: <4A499F1F.2070900@microchip.com>
References: <4A499F1F.2070900@microchip.com>
Message-ID: <b087fca00906300416u6ac1e8b0jd26eea7c170c17b9@mail.gmail.com>

Hello

> 1.  clang-cc needs parentheses or else gives errors. So the actual
> syntax is
>     module asm (" blah ");
I think you confused LLVM IR with C/C++ since you're citing LLVM
langref document but then due to some unknown to me reason tries to
use LLVM IR syntax in C source.

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



From j.stanier at sussex.ac.uk  Tue Jun 30 04:22:45 2009
From: j.stanier at sussex.ac.uk (James Stanier)
Date: Tue, 30 Jun 2009 04:22:45 -0700 (PDT)
Subject: [LLVMdev]  Irreducibility and the -simplifycfg flag
Message-ID: <24270165.post@talk.nabble.com>


Hi everyone,

I'm currently trying to run a study on irreducibility of C programs, and
I've implemented structural analysis (original paper by Sharir, algorithm in
Muchnick's book) as an LLVM pass. When my implementation becomes a bit less
buggy I'll certainly look into including it in the LLVM project. 

As a test for the algorithm I've been producing LLVM bitcode for C files in
the GNU coreutils package. When generating bitcode, I find that sometimes
the CFG produced can have basic blocks that have no successors or
predecessors; using "-view-cfg-only" they just float around on their own,
unconnected to anything in the dot file. This causes upset in the algorithm
at the moment, so I was overcoming the problem by running "-simplify-cfg"
before structural analysis takes place.

My question is this: would the simplify pass ever make a reducible CFG
become irreducible? My current inkling is towards no from what I can see in
the source code and the documentation. However I was wondering if someone
with more experience and understanding of the pass could share some wisdom!
If it does, is there a simpler "clean-up" pass that I could run?

Best wishes,
James
-- 
View this message in context: http://www.nabble.com/Irreducibility-and-the--simplifycfg-flag-tp24270165p24270165.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.



From sanjiv.gupta at microchip.com  Tue Jun 30 05:18:20 2009
From: sanjiv.gupta at microchip.com (Sanjiv Gupta)
Date: Tue, 30 Jun 2009 17:48:20 +0530
Subject: [LLVMdev] Problems with "module asm"
In-Reply-To: <b087fca00906300416u6ac1e8b0jd26eea7c170c17b9@mail.gmail.com>
References: <4A499F1F.2070900@microchip.com>
	<b087fca00906300416u6ac1e8b0jd26eea7c170c17b9@mail.gmail.com>
Message-ID: <4A4A028C.2070404@microchip.com>

Anton Korobeynikov wrote:
> Hello
>
>   
>> 1.  clang-cc needs parentheses or else gives errors. So the actual
>> syntax is
>>     module asm (" blah ");
>>     
> I think you confused LLVM IR with C/C++ since you're citing LLVM
> langref document but then due to some unknown to me reason tries to
> use LLVM IR syntax in C source.
>
>   
You are right. What's the C equivalent? When does clang generates module 
asm?

- Sanjiv


From eli.friedman at gmail.com  Tue Jun 30 05:33:03 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Tue, 30 Jun 2009 05:33:03 -0700
Subject: [LLVMdev] Irreducibility and the -simplifycfg flag
In-Reply-To: <24270165.post@talk.nabble.com>
References: <24270165.post@talk.nabble.com>
Message-ID: <f5aa3e9b0906300533h49774eaai2404c6e2267f1b55@mail.gmail.com>

On Tue, Jun 30, 2009 at 4:22 AM, James Stanier<j.stanier at sussex.ac.uk> wrote:
> My question is this: would the simplify pass ever make a reducible CFG
> become irreducible?

If it does, it's a bug; transforming a reducible CFG into an
irreducible CFG significantly pessimizes the loop analysis passes.
That said, I'm pretty sure it can in some unusual cases. If you care,
a patch to split out the RemoveUnreachableBlocksFromFn helper from
SimplifyCFGPass into a helper available from
llvm/Transforms/Utils/Local.h would be welcome, I think.

That said, it's pretty easy to dodge the issue in your pass by
iterating over the tree of BBs with df_begin/df_end rather than the
list of BBs for the function; see llvm/ADT/DepthFirstIterator.h.

-Eli


From sanjiv.gupta at microchip.com  Tue Jun 30 05:37:46 2009
From: sanjiv.gupta at microchip.com (Sanjiv Gupta)
Date: Tue, 30 Jun 2009 18:07:46 +0530
Subject: [LLVMdev] Problems with "module asm"
In-Reply-To: <4A4A028C.2070404@microchip.com>
References: <4A499F1F.2070900@microchip.com>	<b087fca00906300416u6ac1e8b0jd26eea7c170c17b9@mail.gmail.com>
	<4A4A028C.2070404@microchip.com>
Message-ID: <4A4A071A.6090905@microchip.com>

Sanjiv Gupta wrote:
> Anton Korobeynikov wrote:
>   
>> Hello
>>
>>   
>>     
>>> 1.  clang-cc needs parentheses or else gives errors. So the actual
>>> syntax is
>>>     module asm (" blah ");
>>>     
>>>       
>> I think you confused LLVM IR with C/C++ since you're citing LLVM
>> langref document but then due to some unknown to me reason tries to
>> use LLVM IR syntax in C source.
>>
>>   
>>     
> You are right. What's the C equivalent? When does clang generates module 
> asm?
>
> - Sanjiv
>   
Please ignore that. Eli had already answered that in one of the other 
emails.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   



From davidterei at gmail.com  Tue Jun 30 06:06:50 2009
From: davidterei at gmail.com (David Terei)
Date: Tue, 30 Jun 2009 23:06:50 +1000
Subject: [LLVMdev] Pinning registers in LLVM
In-Reply-To: <BC3393FA-BA57-4D35-ADB4-CEEAA2740820@apple.com>
References: <F8C491D7-1C02-4C61-B690-1D62346EA9F6@gmail.com> 
	<BC3393FA-BA57-4D35-ADB4-CEEAA2740820@apple.com>
Message-ID: <150b8f420906300606s3d7618f4jf61bbf3abf3d7dbb@mail.gmail.com>

2009/6/30 Chris Lattner <clattner at apple.com>:
>
> Interestingly (to me at least :), there is no guarantee that this value
> be in the physreg at a random point in the function.

Yep, also interesting to me though :).

> If it were important to me to implement this, I'd implement this
> extension by adding a new custom calling convention to the X86 backend
> that always passed the first i32 value in ESI and always returned the
> first i32 value in ESI.

Yeah that was my line of thinking as well. Thanks for the detailed response.

~ David


From st at invia.fr  Tue Jun 30 06:11:41 2009
From: st at invia.fr (Sylvere Teissier)
Date: Tue, 30 Jun 2009 15:11:41 +0200
Subject: [LLVMdev] About debug in LLVM!!!
In-Reply-To: <4A48F7E5.4030002@microchip.com>
References: <000901c9f8d1$f7590730$07362c8d@MOIPC7>
	<4A48F7E5.4030002@microchip.com>
Message-ID: <1246367501.12923.4.camel@vostro-1510.invia>

> 2. The backend (llc) converts that to Dwarf (or something else as 
> desired by that back-end).
> 
How advanced is LLVM Dwarf generation compared to GCC ?




From baldrick at free.fr  Tue Jun 30 06:20:08 2009
From: baldrick at free.fr (Duncan Sands)
Date: Tue, 30 Jun 2009 15:20:08 +0200
Subject: [LLVMdev] Irreducibility and the -simplifycfg flag
In-Reply-To: <24270165.post@talk.nabble.com>
References: <24270165.post@talk.nabble.com>
Message-ID: <4A4A1108.3050407@free.fr>

Hi,

>...
> As a test for the algorithm I've been producing LLVM bitcode for C files in
> the GNU coreutils package. When generating bitcode, I find that sometimes
> the CFG produced can have basic blocks that have no successors or
> predecessors; using "-view-cfg-only" they just float around on their own,
> unconnected to anything in the dot file. This causes upset in the algorithm
> at the moment, so I was overcoming the problem by running "-simplify-cfg"
> before structural analysis takes place.
...
> 
> My question is this: would the simplify pass ever make a reducible CFG
> become irreducible? My current inkling is towards no from what I can see in
> the source code and the documentation. However I was wondering if someone
> with more experience and understanding of the pass could share some wisdom!
> If it does, is there a simpler "clean-up" pass that I could run?

you can always write your own mini-pass that just dumps unreachable
basic blocks.

Ciao,

Duncan.


From xerxes at zafena.se  Tue Jun 30 06:52:12 2009
From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=)
Date: Tue, 30 Jun 2009 15:52:12 +0200
Subject: [LLVMdev] cmake configured buildbot
Message-ID: <4A4A188C.4020301@zafena.se>

Greetings

Im interested to setup an automated buildbod that can test the cmake 
buildsysten.
I use cmake for ARM cross compilation so I would be interested if 
someone are running a cmake bot and if its build logs be observed online?
If not, are there an easy way to setup a llvm cmake buildbot that can 
test the cmake build infrastructure for each commit?

Cheers, and have a great day!
Xerxes



From ofv at wanadoo.es  Tue Jun 30 07:13:07 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Tue, 30 Jun 2009 16:13:07 +0200
Subject: [LLVMdev] Urgent fix for MSVC
References: <4A49EFEA.1040509@tu-dresden.de>
Message-ID: <873a9hhkss.fsf@telefonica.net>

Olaf Krzikalla <Olaf.Krzikalla at tu-dresden.de>
writes:

> See the patch and the documentation:

Done. Thanks!

-- 
Óscar



From bharadwajy at gmail.com  Tue Jun 30 08:31:48 2009
From: bharadwajy at gmail.com (S. Bharadwaj Yadavalli)
Date: Tue, 30 Jun 2009 11:31:48 -0400
Subject: [LLVMdev] CROSS COMPILING LLVM
In-Reply-To: <f88b89a50906291425g5116b44med3d8760ea4fff36@mail.gmail.com>
References: <20090610171705.9A51E606897@ws1-4.us4.outblaze.com> 
	<f88b89a50906111918ja679b19o82b66e0980b9cbbf@mail.gmail.com> 
	<0A2B3482-1FB2-4934-B16B-92E070BB6351@apple.com>
	<f88b89a50906291425g5116b44med3d8760ea4fff36@mail.gmail.com>
Message-ID: <d8adb8240906300831i3ec8ed21hcaffd4db245fda9c@mail.gmail.com>

Misha,

I reported this about 10 days ago and Evan has fixed this problem.
http://llvm.org/bugs/show_bug.cgi?id=4416. I was able to build llvm
cross compiler a couple of days with no problem.

Bharadwaj

On Mon, Jun 29, 2009 at 5:25 PM, Misha Brukman<brukman at gmail.com> wrote:
> 2009/6/12 Bob Wilson <bob.wilson at apple.com>
>>
>> Thanks, this should be useful.  What problem did you have with svn
>> revisions after 70786?
>
>  /tmp/llvm-project.p28262/obj/llvm-gcc-4.2/./gcc/xgcc -B/tmp/llvm-project.p28262/obj/llvm-gcc-4.2/./gcc/ -B/tmp/llvm-73246/llvm-project/x86_64-unknown-linux-gnu/arm-none-linux-gnueabi/llvm-gcc-4.2/arm-none-linux-gnueabi/bin/ -B/tmp/llvm-73246/llvm-project/x86_64-unknown-linux-gnu/arm-none-linux-gnueabi/llvm-gcc-4.2/arm-none-linux-gnueabi/lib/ -isystem /tmp/llvm-73246/llvm-project/x86_64-unknown-linux-gnu/arm-none-linux-gnueabi/llvm-gcc-4.2/arm-none-linux-gnueabi/include -isystem /tmp/llvm-73246/llvm-project/x86_64-unknown-linux-gnu/arm-none-linux-gnueabi/llvm-gcc-4.2/arm-none-linux-gnueabi/sys-include -DHAVE_CONFIG_H -I. -I/tmp/llvm-project.p28262/src/llvm-gcc-4.2/libmudflap -I. -Wall -ffunction-sections -fdata-sections -O2 -g -O2 -MT mf-heuristics.lo -MD -MP -MF .deps/mf-heuristics.Tpo -c /tmp/llvm-project.p28262/src/llvm-gcc-4.2/libmudflap/mf-heuristics.c  -fPIC -DPIC -o .libs/mf-heuristics.o
> cc1: /tmp/llvm-project.p28262/src/llvm/include/llvm/CodeGen/LiveIntervalAnalysis.h:134: llvm::LiveInterval& llvm::LiveIntervals::getInterval(unsigned int): Assertion `I != r2iMap_.end() && "Interval does not exist for register"' failed.
> /tmp/llvm-project.p28262/src/llvm-gcc-4.2/libmudflap/mf-heuristics.c:175: internal compiler error: Aborted
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://llvm.org/bugs/> for instructions.
> make[4]: *** [mf-heuristics.lo] Error 1
> make[4]: Leaving directory `/tmp/llvm-project.p28262/obj/llvm-gcc-4.2/arm-none-linux-gnueabi/libmudflap'
> I don't have my build tree any longer that has the intermediate object
> files, so I'll try to re-create it so I can disect the .bc file to figure
> out what's wrong here.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>



From MichaelGraumann at gmx.net  Tue Jun 30 08:33:44 2009
From: MichaelGraumann at gmx.net (Michael Graumann)
Date: Tue, 30 Jun 2009 17:33:44 +0200
Subject: [LLVMdev] modifying llc asm output
Message-ID: <000f01c9f998$28625d10$79271730$@net>

Hi

I am trying to modify the llc in that way: 

 

        subf 3, 5, 3                                 subf 3, 5, 3

        stw 3, 44(1)                                stw 3, 44(1)

                                                               # InlineAsm
Start

                                               -->          isync

                                                               # InlineAsm
End

        lwz 3, 44(1)                                lwz 3, 44(1)

        cmpwi 0, 3, -1                           cmpwi 0, 3, -1

 

I would like to insert Code (like the isync) in the asm output of the llc.
What is the best way, or easiest to do this. 

 

llc -filetype=asm -march=ppc32   -o=test.s test.bc      

 

With best regards,

- Michael

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090630/ee2157a6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6952 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090630/ee2157a6/attachment.bin>

From dbertouille at franticfilms.com  Tue Jun 30 08:37:17 2009
From: dbertouille at franticfilms.com (David Bertouille)
Date: Tue, 30 Jun 2009 10:37:17 -0500
Subject: [LLVMdev] JIT on Windows x64
Message-ID: <4A4A312D.7090404@franticfilms.com>

Hi,
I'm new to LLVM and have some questions about using the JIT on Windows 
x64.  I am aware that this is currently broken but am attempting to use 
the hack/patch proposed in this bug 
http://llvm.org/bugs/show_bug.cgi?id=3739. 

I checked out the revision the patch was created for (66183) and applied 
it but the assembler generated seems to fail whenever it reaches a 
movaps insctruction.
eg.
  movaps      xmmword ptr [rsp+20h],xmm8
  movaps      xmmword ptr [rsp+30h],xmm7
  movaps      xmmword ptr [rsp+40h],xmm6

Would this have something to do with the stack alignment?

I am wondering if anybody else has had any success using that patch to 
get Windows x64 JIT to work correctly.  Or if my problem may be unrelated.

Any suggestions would be useful.





From daniel at zuster.org  Tue Jun 30 08:46:28 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Tue, 30 Jun 2009 08:46:28 -0700
Subject: [LLVMdev] Profiling in LLVM Patch
In-Reply-To: <4A48C2CC.4060708@student.tuwien.ac.at>
References: <4A48C2CC.4060708@student.tuwien.ac.at>
Message-ID: <6a8523d60906300846n13fff721g6b142a0803499482@mail.gmail.com>

Hi Andreas,

Thanks for submitting this back, I intend to review this today. Since
its a big patch, I wanted to point this out on the list in case anyone
else started tackling it.

 - Daniel

On Mon, Jun 29, 2009 at 6:34 AM, Andreas
Neustifter<e0325716 at student.tuwien.ac.at> wrote:
> Hi all,
>
> as proposed in
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-February/020396.html
> I implemented the algorithm presented in [Ball94]. It only instruments
> the minimal number of edges necessary for edge profiling.
>
> The main changes introduced by this patch are:
> *) a interface compatible rewrite of ProfileInfo
> *) a cleanup of ProfileInfoLoader
>   (some functionality in ProfileInfoLoader was duplicated in ProfileInfo or
>   ProfileInfoLoaderPass; ProfileInfoLoader now really only performs the
>   loading but not the post-processing)
> *) a new instrumentation pass that performs the optimal edge profiling
>   instrumentation
> *) a helper module MaximumSpanningTree that selects the edges with have to
>   be instrumented for optimal edge profiling
> *) a ProfileEstimatorPass that does an offline estimation of a profile based
>   on branching and loop depth (also proposed in [Ball94])
>   (it is possible to use this ProfileEstimator stand-alone to have at least
>   some profile estimation available in the frontend without doing profiling
>   runs)
> *) a ProfileVerifierPass that checks the current profiling information
>   against the flow preservation rules
>
> I did performance measurements on the C and C++ portions of the SPEC CPU2000
> benchmark, the results are:
> *) on average 46% of the edges are instrumented with a counter (in
>   comparison to 100% with the current edge profiling)
> *) the performance overhead (on linux-x68_64, other platforms to follow) was
>   14.76% with the current profiling and 8.20% with the optimal profiling
>   (there are strange effects with the mcf and equake benchmarks where the
>   current edge profiling is as fast as the un-instrumented code whereas the
>   optimally instrumented code has a small (~5%) performance overhead)
> *) when mcf and equake are excluded the average performance overhead is
>   51.31% with optimal profiling (in comparison to 100% with the current
>   edge profiling)
>
> Please tell me what you do not like and if this is interesting enough to be
> added to the trunk, if so, I will also devise test cases for "make check".
>
> If you do not like the size of this patch it is possible to break it up a
> little. I did not use the mkpatch utility since it does not include added
> files, I hope the format is readable enough (it should be...)
>
> I ran "make check" and there are not additional errors introduced
> by the patch.
>
> Grettings,
>
> Andreas Neustifter
>
> [Ball94] Thomas Ball, James R. Larus:
> "Optimally profiling and tracing programs"
> ACM TOPLAS, Volume 16, Issue 4, 1994
> http://portal.acm.org/citation.cfm?id=183527
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>



From dbertouille at franticfilms.com  Tue Jun 30 10:09:36 2009
From: dbertouille at franticfilms.com (David Bertouille)
Date: Tue, 30 Jun 2009 12:09:36 -0500
Subject: [LLVMdev] JIT on Windows x64
In-Reply-To: <4A4A312D.7090404@franticfilms.com>
References: <4A4A312D.7090404@franticfilms.com>
Message-ID: <4A4A46D0.2080307@franticfilms.com>

I also have an example that may be useful.  I have the following code 
which takes a pointer to a vector.  The argument is a i8* since in the 
actual implementation that data type is variable but here i simply 
assume it is a pointer to 3 floats.  There is obviously a lot of 
wasteful steps in this code but it is unoptimized and a small part of a 
larger project.

The following code runs fine until i add the last step( writing from 
stack to the dataPtr). When those lines are added the code crashes on a 
movaps instruction.
 The extra lines appended (right before the ret void) are:

        %27 = load float* %outStackPtr          ; <float> [#uses=1]
        store float %27, float* %0
        %28 = getelementptr float* %outStackPtr, i32 1          ; 
<float*> [#uses=2]
        %29 = getelementptr float* %0, i32 1            ; <float*> [#uses=2]
        %30 = load float* %28           ; <float> [#uses=1]
        store float %30, float* %29
        %31 = getelementptr float* %28, i32 1           ; <float*> [#uses=1]
        %32 = getelementptr float* %29, i32 1           ; <float*> [#uses=1]
        %33 = load float* %31           ; <float> [#uses=1]
        store float %33, float* %32


Working Code:

; ModuleID = 'module'
target datalayout = "e"

define void @main(i8* %dataPtr) {
mainBB:
        %inStackPtr = alloca float, i32 3               ; <float*> [#uses=4]
        %0 = bitcast i8* %dataPtr to float*             ; <float*> [#uses=2]
        %1 = load float* %0             ; <float> [#uses=1]
        store float %1, float* %inStackPtr
        %2 = getelementptr float* %inStackPtr, i32 1            ; 
<float*> [#uses=2]
        %3 = getelementptr float* %0, i32 1             ; <float*> [#uses=2]
        %4 = load float* %3             ; <float> [#uses=1]
        store float %4, float* %2
        %5 = getelementptr float* %2, i32 1             ; <float*> [#uses=1]
        %6 = getelementptr float* %3, i32 1             ; <float*> [#uses=1]
        %7 = load float* %6             ; <float> [#uses=1]
        store float %7, float* %5
        %8 = load float* %inStackPtr            ; <float> [#uses=3]
        %9 = getelementptr float* %inStackPtr, i32 1            ; 
<float*> [#uses=2]
        %10 = load float* %9            ; <float> [#uses=3]
        %11 = getelementptr float* %9, i32 1            ; <float*> [#uses=2]
        %12 = load float* %11           ; <float> [#uses=3]
        %13 = getelementptr float* %11, i32 1           ; <float*> [#uses=0]
        %14 = mul float %8, %8          ; <float> [#uses=1]
        %15 = mul float %10, %10                ; <float> [#uses=1]
        %16 = add float %14, %15                ; <float> [#uses=1]
        %17 = mul float %12, %12                ; <float> [#uses=1]
        %18 = add float %16, %17                ; <float> [#uses=1]
        %19 = fpext float %18 to double         ; <double> [#uses=1]
        %20 = call double @sqrt(double %19)             ; <double> [#uses=1]
        %21 = fptrunc double %20 to float               ; <float> [#uses=3]
        %outStackPtr = alloca float, i32 3              ; <float*> [#uses=2]
        %22 = fdiv float %8, %21                ; <float> [#uses=1]
        store float %22, float* %outStackPtr
        %23 = getelementptr float* %outStackPtr, i32 1          ; 
<float*> [#uses=2]
        %24 = fdiv float %10, %21               ; <float> [#uses=1]
        store float %24, float* %23
        %25 = getelementptr float* %23, i32 1           ; <float*> [#uses=1]
        %26 = fdiv float %12, %21               ; <float> [#uses=1]
        store float %26, float* %25
        ret void
}

declare double @sqrt(double)



David Bertouille wrote:
> Hi,
> I'm new to LLVM and have some questions about using the JIT on Windows 
> x64.  I am aware that this is currently broken but am attempting to use 
> the hack/patch proposed in this bug 
> http://llvm.org/bugs/show_bug.cgi?id=3739. 
>
> I checked out the revision the patch was created for (66183) and applied 
> it but the assembler generated seems to fail whenever it reaches a 
> movaps insctruction.
> eg.
>   movaps      xmmword ptr [rsp+20h],xmm8
>   movaps      xmmword ptr [rsp+30h],xmm7
>   movaps      xmmword ptr [rsp+40h],xmm6
>
> Would this have something to do with the stack alignment?
>
> I am wondering if anybody else has had any success using that patch to 
> get Windows x64 JIT to work correctly.  Or if my problem may be unrelated.
>
> Any suggestions would be useful.
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> __________ NOD32 4184 (20090624) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
>
>
>
>   



From clattner at apple.com  Tue Jun 30 10:12:45 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 30 Jun 2009 10:12:45 -0700
Subject: [LLVMdev] Mismatched caller/callee + unreachable
Message-ID: <02D37E83-A207-4B34-A9AE-10ED6CB3BEF4@apple.com>

If you have been wondering why the verifier doesn't reject calls and  
callees with mismatched calling convs, any why the optimizer  
mercilessly deletes them, there is a new FAQ here:
http://llvm.org/docs/FAQ.html#callconvwrong

-Chris 


From isanbard at gmail.com  Tue Jun 30 10:15:39 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Tue, 30 Jun 2009 10:15:39 -0700
Subject: [LLVMdev] modifying llc asm output
In-Reply-To: <000f01c9f998$28625d10$79271730$@net>
References: <000f01c9f998$28625d10$79271730$@net>
Message-ID: <16e5fdf90906301015u1b31c689l389e703eb2e5db71@mail.gmail.com>

On Tue, Jun 30, 2009 at 8:33 AM, Michael
Graumann<MichaelGraumann at gmx.net> wrote:
> Hi
>
> I am trying to modify the llc in that way:
>
>
>
>         subf 3, 5, 3                                 subf 3, 5, 3
>
>         stw 3, 44(1)                                stw 3, 44(1)
>
>                                                                # InlineAsm
> Start
>
>                                                -->          isync
>
>                                                                # InlineAsm
> End
>
>         lwz 3, 44(1)                                lwz 3, 44(1)
>
>         cmpwi 0, 3, -1                           cmpwi 0, 3, -1
>
>
>
> I would like to insert Code (like the isync) in the asm output of the llc.
> What is the best way, or easiest to do this.
>
Well, inlined assembly, of course. :-) Make sure to mark it as "volatile".

-bw



From anton at korobeynikov.info  Tue Jun 30 10:15:40 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Tue, 30 Jun 2009 21:15:40 +0400
Subject: [LLVMdev] JIT on Windows x64
In-Reply-To: <4A4A312D.7090404@franticfilms.com>
References: <4A4A312D.7090404@franticfilms.com>
Message-ID: <b087fca00906301015l1f4ff4b1qb13d9a80a7bc9ede@mail.gmail.com>

Hello, David

> I'm new to LLVM and have some questions about using the JIT on Windows
> x64.  I am aware that this is currently broken but am attempting to use
> the hack/patch proposed in this bug
> http://llvm.org/bugs/show_bug.cgi?id=3739.
I have a patch locally which might unbreak win64 (at least tests
reports so). I hope to commit it soon

> Would this have something to do with the stack alignment?
No. AFAIR masm has several stupid limitations:
 1. Only very recent versions support SSE2 stuff
 2. You need to emit some magic directive to allow it understand the
instructions properly

> I am wondering if anybody else has had any success using that patch t
> get Windows x64 JIT to work correctly.  Or if my problem may be unrelated.
I don't see how assembler problems are connected with JIT.

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



From juanc.martinez.santos at gmail.com  Tue Jun 30 10:18:48 2009
From: juanc.martinez.santos at gmail.com (Juan Carlos Martinez Santos)
Date: Tue, 30 Jun 2009 13:18:48 -0400
Subject: [LLVMdev] Generatin code for an ARM-LINUX machine
In-Reply-To: <f88b89a50906291423t771f371fnccc1bab77c715155@mail.gmail.com>
References: <d17b77a40906291409g11dac454pebca2253499df2e1@mail.gmail.com>
	<f88b89a50906291423t771f371fnccc1bab77c715155@mail.gmail.com>
Message-ID: <d17b77a40906301018k4d3a9b01ud8a51d720c5154b8@mail.gmail.com>

Thanks Misha,

However, I could not find the crosstool. Could you please check the name of
the script?

Regards,

Juan Carlos

On Mon, Jun 29, 2009 at 5:23 PM, Misha Brukman <brukman at gmail.com> wrote:

> I have not used llvmc to build ARM binaries, but llvm-gcc does work.There's
> a script to build llvm-gcc x86 -> ARM cross-compiler in
> llvm/utils/crosstool/ARM/ .
>
> 2009/6/29 Juan Carlos Martinez Santos <juanc.martinez.santos at gmail.com>
>
>> I am using the below configuration:
>>
>> ./configure --with-llvmgccdir=/home/jcmartin78/LLVM/llvm-gcc4.2
>> --prefix=/home/jcmartin78/local --enable-optimized=1 --enable-debug-runtime
>> --enable-jit --enable-targets=arm --target=arm
>>
>> When I use LLVMC to compile a simple program I get this:
>>
>> $ llvmc hello.c
>> llc: error auto-selecting target for module 'No available targets are
>> compatible with this module'.  Please use the -march option to explicitly
>> pick a target.
>>
>> Using the -march options, I get this:
>>
>> $ llvmc -march=arm hello.c
>> hello.c:1: error: bad value (arm) for -march= switch
>> hello.c:1: error: bad value (arm) for -mtune= switch
>>
>> Somebody has an idea what is wrong in my procedure? I am using a x86-linux
>> machine and I want to generate code for an arm-linux machine (also, I am
>> using the binutils 2.19 to build my cross-compiler).
>>
>> --
>> Juan Carlos
>>
>> _______________________________________________
>> 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
>
>


-- 
Juan Carlos Martínez Santos
242 Foster Drive Apt H
Colonial Townhouse Apartments
Willimantic, CT 06226-1538
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090630/dab81a9b/attachment.html>

From ojomojo at gmail.com  Tue Jun 30 10:32:12 2009
From: ojomojo at gmail.com (John Mosby)
Date: Tue, 30 Jun 2009 11:32:12 -0600
Subject: [LLVMdev] Generatin code for an ARM-LINUX machine
In-Reply-To: <d17b77a40906301018k4d3a9b01ud8a51d720c5154b8@mail.gmail.com>
References: <d17b77a40906291409g11dac454pebca2253499df2e1@mail.gmail.com>
	<f88b89a50906291423t771f371fnccc1bab77c715155@mail.gmail.com>
	<d17b77a40906301018k4d3a9b01ud8a51d720c5154b8@mail.gmail.com>
Message-ID: <645d868c0906301032s187cbf1do2019e967a8b6310e@mail.gmail.com>

llvm/utils/crosstool/ARM/build-install-linux.sh

On Tue, Jun 30, 2009 at 11:18 AM, Juan Carlos Martinez Santos <
juanc.martinez.santos at gmail.com> wrote:

> Thanks Misha,
>
> However, I could not find the crosstool. Could you please check the name of
> the script?
>
> Regards,
>
> Juan Carlos
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090630/c190662f/attachment.html>

From xykong at yahoo.com  Tue Jun 30 11:05:45 2009
From: xykong at yahoo.com (Xiangyun Kong)
Date: Tue, 30 Jun 2009 11:05:45 -0700 (PDT)
Subject: [LLVMdev] About using ParseCommandLine
Message-ID: <674526.18654.qm@web82102.mail.mud.yahoo.com>


I need to use LLVM's command line utilities for parsing command line
in an online compiling mode. Since multiple program may be compiled online
with same or different command line options, the options states need to
be saved and restored.

I found it is hard to save and restore 
opt (options), given that opt are defined with 
C++ templates, and options are registered implicitly through
class constructor.

Not sure if anyone else got the same problems. It will be nice to
add some infrastructural changes to Opt/Option so that the states of
Opt/Option can be saved and restored in a central place.

Any comments or suggestions ?

Thanks.

Xiangyun




From MichaelGraumann at gmx.net  Tue Jun 30 11:16:32 2009
From: MichaelGraumann at gmx.net (Michael Graumann)
Date: Tue, 30 Jun 2009 20:16:32 +0200
Subject: [LLVMdev] modifying llc asm output
In-Reply-To: <16e5fdf90906301015u1b31c689l389e703eb2e5db71@mail.gmail.com>
References: <000f01c9f998$28625d10$79271730$@net>
	<16e5fdf90906301015u1b31c689l389e703eb2e5db71@mail.gmail.com>
Message-ID: <001701c9f9ae$e727a2d0$b576e870$@net>

Ok :-) und how can I add inlined assembly to the output?

- Michael

-----Ursprüngliche Nachricht-----
Von: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] Im
Auftrag von Bill Wendling
Gesendet: Dienstag, 30. Juni 2009 19:16
An: LLVM Developers Mailing List
Betreff: Re: [LLVMdev] modifying llc asm output

On Tue, Jun 30, 2009 at 8:33 AM, Michael
Graumann<MichaelGraumann at gmx.net> wrote:
> Hi
>
> I am trying to modify the llc in that way:
>
>
>
>         subf 3, 5, 3                                 subf 3, 5, 3
>
>         stw 3, 44(1)                                stw 3, 44(1)
>
>                                                                # InlineAsm
> Start
>
>                                                -->          isync
>
>                                                                # InlineAsm
> End
>
>         lwz 3, 44(1)                                lwz 3, 44(1)
>
>         cmpwi 0, 3, -1                           cmpwi 0, 3, -1
>
>
>
> I would like to insert Code (like the isync) in the asm output of the llc.
> What is the best way, or easiest to do this.
>
Well, inlined assembly, of course. :-) Make sure to mark it as "volatile".

-bw

_______________________________________________
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/x-pkcs7-signature
Size: 6952 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090630/f6e3e133/attachment.bin>

From jyasskin at google.com  Tue Jun 30 11:18:54 2009
From: jyasskin at google.com (Jeffrey Yasskin)
Date: Tue, 30 Jun 2009 11:18:54 -0700
Subject: [LLVMdev] JIT allocates global data in function body memory
In-Reply-To: <D188A28D-BA9C-4262-81BE-6CAB4BBCEBF7@apple.com>
References: <9a9942200906291741p366b5c23qa52180bbb071d908@mail.gmail.com>
	<D188A28D-BA9C-4262-81BE-6CAB4BBCEBF7@apple.com>
Message-ID: <bb55930e0906301118i30c811cbtf5f870c26db97b62@mail.gmail.com>

On Mon, Jun 29, 2009 at 5:50 PM, Dale Johannesen<dalej at apple.com> wrote:
>
> On Jun 29, 2009, at 5:41 PMPDT, Reid Kleckner wrote:
>
>> So I (think I) found a bug in the JIT:
>> http://llvm.org/bugs/show_bug.cgi?id=4483
>>
>> Basically, globals used by a function are allocated in the same buffer
>> as the first code that uses it.  However, when you free the machine
>> code, you also free the memory holding the global's data.  The address
>> is still in the GlobalValue map, so any other code using that global
>> will access freed memory, which will cause problems as soon as you
>> reallocate that memory for something else.
>>
>> I tracked down the commit that introduced the bug:
>> http://llvm.org/viewvc/llvm-project?view=rev&revision=54442
>>
>> It very nicely explains what it does, but not why it does it, which
>> I'd like to know before I change it.  I couldn't find the author
>> (johannes) on IRC so ssen told me to ask LLVMdev about this behavior.
>
> That's me (and I'm not on IRC because I like messages to be
> archived).  The reason everything needs to go in the same buffer is
> that we're JITting code on one machine, then sending it to another to
> be executed, and references from one buffer to another won't work in
> that environment.  So that model needs to continue to work.  If you
> want to generalize it so other models work as well, go ahead.

So, you're moving code across machines without running any relocations
on it? How can that work? Are you just assuming that everything winds
up at the same addresses? Or is everything PC-relative on your
platform, so all that matters is that globals and the code are in the
same relative positions?

How are you getting the size of the code you need to copy?
MachineCodeInfo didn't exist when you wrote this patch, so I assume
you've written your own JITMemoryManager. Even then, if you JIT more
than one function, and they share any globals, you have to deal with
multiple calls into the MemoryManager and functions that use globals
allocated inside other buffers. You should be able to deal with having
separate calls to allocate global space and allocate code space. You'd
just remember the answers you gave and preserve them when copying to a
new system.

I'd like freeMachineCodeForFunction to avoid corrupting emitted
globals, and with the current arrangement of information within the
JIT, that means globals and code have to live in different
allocations. I think Reid's suggesting a flag of some sort, with one
setting for "freeMachineCodeForFunction works" and another for
"globals and code are allocated by a single call into the
MemoryManager." I'd like to avoid new knobs if it's possible, so do
you really need that second option? Or do you just need globals to be
allocated by some call into the MemoryManager?

Thanks!
Jeffrey



From nlewycky at google.com  Tue Jun 30 11:29:20 2009
From: nlewycky at google.com (Nick Lewycky)
Date: Tue, 30 Jun 2009 11:29:20 -0700
Subject: [LLVMdev] build failure on ARM linux
Message-ID: <fd63e6a40906301129j30b40665y13d13f71de3ce66e@mail.gmail.com>

I'm seeing this new build failure, starting some time yesterday on ARM:

make[3]: Entering directory `/home/nlewycky/llvm/tools/llvmc/driver'
llvm[3]: Linking Debug executable llvmc
g++ -DLLVMC_BUILTIN_PLUGIN_1=Base -DLLVMC_BUILTIN_PLUGIN_2=Clang
-I/home/nlewycky/llvm/include -I/home/nlewycky/llvm/tools/llvmc/driver
 -D_DEBUG  -D_GNU_SOURCE -D__STDC_LIMIT_MACROS
-D__STDC_CONSTANT_MACROS -g -fPIC  -Woverloaded-virtual   -pedantic
-Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings
-lCompilerDriver -g  -Wl,-R -Wl,/home/nlewycky/llvm/Debug/bin
-Wl,-export-dynamic -L/home/nlewycky/llvm/Debug/lib
-L/home/nlewycky/llvm/Debug/lib  -o
/home/nlewycky/llvm/Debug/bin/llvmc
/home/nlewycky/llvm/tools/llvmc/driver/Debug/Main.o
-lplugin_llvmc_Base -lplugin_llvmc_Clang \
           -lpthread -ldl -lm
/usr/bin/ld: /home/nlewycky/llvm/Debug/bin/llvmc: hidden symbol
`__sync_val_compare_and_swap_4' in
/usr/lib/gcc/arm-linux-gnueabi/4.3.3/libgcc.a(linux-atomic.o) is
referenced by DSO
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
make[3]: *** [/home/nlewycky/llvm/Debug/bin/llvmc] Error 1

This is with LLVM being built by the system compiler (GCC 4.3.3-10 Debian).
I'm not sure what to make of this. Would it be due to the atomics used for
mutexes?

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090630/b2c4b768/attachment.html>

From david_goodwin at apple.com  Tue Jun 30 11:39:15 2009
From: david_goodwin at apple.com (David Goodwin)
Date: Tue, 30 Jun 2009 11:39:15 -0700
Subject: [LLVMdev] =?windows-1252?q?llvm-gcc-4=2E2_build_failure=3A_llvm-c?=
 =?windows-1252?q?onvert=2Ecpp=3A=91ReplacementStrings=92_may_be_used_unin?=
 =?windows-1252?q?itialized_in_this_function?=
Message-ID: <BB2B4A4C-FBD0-4E40-8397-2608EBF5A732@apple.com>

g++ -m32 -c -g -O2 -mdynamic-no-pic -DIN_GCC -W -Wall -Wwrite-strings - 
pedantic -Wno-long-long -Wno-variadic-macros -Wmissing-format- 
attribute -Werror -mdynamic-no-pic -DHAVE_CONFIG_H -Wno-unused - 
DTARGET_NAME=\"i686-apple-darwin9\" -DNDEBUG -I. -I. -I/tmp/ 
llvmgcc42.roots/llvmgcc42~obj/src/gcc -I/tmp/llvmgcc42.roots/ 
llvmgcc42~obj/src/gcc/. -I/tmp/llvmgcc42.roots/llvmgcc42~obj/src/ 
gcc/../include -I./../intl -I/tmp/llvmgcc42.roots/llvmgcc42~obj/src/ 
gcc/../libcpp/include  -I/tmp/llvmgcc42.roots/llvmgcc42~obj/src/gcc/../ 
libdecnumber -I../libdecnumber -I/tmp/llvmCore.roots/llvmCore~dst/ 
Developer/usr/local/include -I/tmp/llvmCore.roots/llvmCore~obj/src/ 
include -DENABLE_LLVM -I/tmp/llvmCore.roots/llvmCore~dst/Developer/usr/ 
local/include  -D_DEBUG  -D_GNU_SOURCE -D__STDC_LIMIT_MACROS - 
D__STDC_CONSTANT_MACROS -DLLVM_VERSION_INFO='"063009"' - 
DBUILD_LLVM_APPLE_STYLE   -I. -I. -I/tmp/llvmgcc42.roots/llvmgcc42~obj/ 
src/gcc -I/tmp/llvmgcc42.roots/llvmgcc42~obj/src/gcc/. -I/tmp/ 
llvmgcc42.roots/llvmgcc42~obj/src/gcc/../include -I./../intl -I/tmp/ 
llvmgcc42.roots/llvmgcc42~obj/src/gcc/../libcpp/include  -I/tmp/ 
llvmgcc42.roots/llvmgcc42~obj/src/gcc/../libdecnumber -I../ 
libdecnumber -I/tmp/llvmCore.roots/llvmCore~dst/Developer/usr/local/ 
include -I/tmp/llvmCore.roots/llvmCore~obj/src/include /tmp/ 
llvmgcc42.roots/llvmgcc42~obj/src/gcc/llvm-debug.cpp -o llvm-debug.o
cc1plus: warnings being treated as errors
/tmp/llvmgcc42.roots/llvmgcc42~obj/src/gcc/llvm-convert.cpp: In member  
function ‘llvm::Value* TreeToLLVM::EmitASM_EXPR(tree_node*)’:
/tmp/llvmgcc42.roots/llvmgcc42~obj/src/gcc/llvm-convert.cpp:4112:  
warning: ‘ReplacementStrings’ may be used uninitialized in this function





From aph at redhat.com  Tue Jun 30 11:42:18 2009
From: aph at redhat.com (Andrew Haley)
Date: Tue, 30 Jun 2009 19:42:18 +0100
Subject: [LLVMdev] build failure on ARM linux
In-Reply-To: <fd63e6a40906301129j30b40665y13d13f71de3ce66e@mail.gmail.com>
References: <fd63e6a40906301129j30b40665y13d13f71de3ce66e@mail.gmail.com>
Message-ID: <4A4A5C8A.1020103@redhat.com>

Nick Lewycky wrote:
> I'm seeing this new build failure, starting some time yesterday on ARM:
> 
> make[3]: Entering directory `/home/nlewycky/llvm/tools/llvmc/driver'
> llvm[3]: Linking Debug executable llvmc
> g++ -DLLVMC_BUILTIN_PLUGIN_1=Base -DLLVMC_BUILTIN_PLUGIN_2=Clang -I/home/nlewycky/llvm/include -I/home/nlewycky/llvm/tools/llvmc/driver  -D_DEBUG  -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -g -fPIC  -Woverloaded-virtual   -pedantic -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings  -lCompilerDriver -g  -Wl,-R -Wl,/home/nlewycky/llvm/Debug/bin -Wl,-export-dynamic -L/home/nlewycky/llvm/Debug/lib -L/home/nlewycky/llvm/Debug/lib  -o /home/nlewycky/llvm/Debug/bin/llvmc  /home/nlewycky/llvm/tools/llvmc/driver/Debug/Main.o -lplugin_llvmc_Base -lplugin_llvmc_Clang \
>            -lpthread -ldl -lm 
> /usr/bin/ld: /home/nlewycky/llvm/Debug/bin/llvmc: hidden symbol `__sync_val_compare_and_swap_4' in /usr/lib/gcc/arm-linux-gnueabi/4.3.3/libgcc.a(linux-atomic.o) is referenced by DSO
> /usr/bin/ld: final link failed: Nonrepresentable section on output
> collect2: ld returned 1 exit status
> make[3]: *** [/home/nlewycky/llvm/Debug/bin/llvmc] Error 1
> 
> This is with LLVM being built by the system compiler (GCC 4.3.3-10
> Debian). I'm not sure what to make of this. Would it be due to the
> atomics used for mutexes?

Yes.  It's just a matter of defining __sync_val_compare_and_swap_4:

http://gcc.gnu.org/svn/gcc/trunk/gcc/config/arm/linux-atomic.c

Andrew.


From dalej at apple.com  Tue Jun 30 11:42:48 2009
From: dalej at apple.com (Dale Johannesen)
Date: Tue, 30 Jun 2009 11:42:48 -0700
Subject: [LLVMdev] JIT allocates global data in function body memory
In-Reply-To: <bb55930e0906301118i30c811cbtf5f870c26db97b62@mail.gmail.com>
References: <9a9942200906291741p366b5c23qa52180bbb071d908@mail.gmail.com>
	<D188A28D-BA9C-4262-81BE-6CAB4BBCEBF7@apple.com>
	<bb55930e0906301118i30c811cbtf5f870c26db97b62@mail.gmail.com>
Message-ID: <D557CD2A-54B9-40BC-AA6C-4CB4880C5D17@apple.com>


On Jun 30, 2009, at 11:18 AMPDT, Jeffrey Yasskin wrote:

> On Mon, Jun 29, 2009 at 5:50 PM, Dale Johannesen<dalej at apple.com>  
> wrote:
>>
>> On Jun 29, 2009, at 5:41 PMPDT, Reid Kleckner wrote:
>>
>>> So I (think I) found a bug in the JIT:
>>> http://llvm.org/bugs/show_bug.cgi?id=4483
>>>
>>> Basically, globals used by a function are allocated in the same  
>>> buffer
>>> as the first code that uses it.  However, when you free the machine
>>> code, you also free the memory holding the global's data.  The  
>>> address
>>> is still in the GlobalValue map, so any other code using that global
>>> will access freed memory, which will cause problems as soon as you
>>> reallocate that memory for something else.
>>>
>>> I tracked down the commit that introduced the bug:
>>> http://llvm.org/viewvc/llvm-project?view=rev&revision=54442
>>>
>>> It very nicely explains what it does, but not why it does it, which
>>> I'd like to know before I change it.  I couldn't find the author
>>> (johannes) on IRC so ssen told me to ask LLVMdev about this  
>>> behavior.
>>
>> That's me (and I'm not on IRC because I like messages to be
>> archived).  The reason everything needs to go in the same buffer is
>> that we're JITting code on one machine, then sending it to another to
>> be executed, and references from one buffer to another won't work in
>> that environment.  So that model needs to continue to work.  If you
>> want to generalize it so other models work as well, go ahead.
>
> So, you're moving code across machines without running any relocations
> on it? How can that work? Are you just assuming that everything winds
> up at the same addresses? Or is everything PC-relative on your
> platform, so all that matters is that globals and the code are in the
> same relative positions?

I am not the people actually doing this, I am the guy who changed llvm  
JIT handling so that this model would work.  I believe everything is  
PC-relative, but I don't know details (and probably couldn't talk  
about them on a public list if I did).  I don't think those guys do  
any freeing, so they don't have your problem.

The current model where code and data share a buffer needs to continue  
to work, and I have a fairly strong preference (and so will our  
client) that whatever you do should not require any changes to the  
existing client code.  Beyond that, I am not the kind of person who  
thinks there's only one way to do things; I won't object to what you  
do as long as it doesn't break what we're using now.

> How are you getting the size of the code you need to copy?
> MachineCodeInfo didn't exist when you wrote this patch, so I assume
> you've written your own JITMemoryManager. Even then, if you JIT more
> than one function, and they share any globals, you have to deal with
> multiple calls into the MemoryManager and functions that use globals
> allocated inside other buffers. You should be able to deal with having
> separate calls to allocate global space and allocate code space. You'd
> just remember the answers you gave and preserve them when copying to a
> new system.
>
> I'd like freeMachineCodeForFunction to avoid corrupting emitted
> globals, and with the current arrangement of information within the
> JIT, that means globals and code have to live in different
> allocations. I think Reid's suggesting a flag of some sort, with one
> setting for "freeMachineCodeForFunction works" and another for
> "globals and code are allocated by a single call into the
> MemoryManager." I'd like to avoid new knobs if it's possible, so do
> you really need that second option? Or do you just need globals to be
> allocated by some call into the MemoryManager?
>
> Thanks!
> Jeffrey
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



From ojomojo at gmail.com  Tue Jun 30 11:47:54 2009
From: ojomojo at gmail.com (John Mosby)
Date: Tue, 30 Jun 2009 12:47:54 -0600
Subject: [LLVMdev] build failure on ARM linux
In-Reply-To: <fd63e6a40906301129j30b40665y13d13f71de3ce66e@mail.gmail.com>
References: <fd63e6a40906301129j30b40665y13d13f71de3ce66e@mail.gmail.com>
Message-ID: <645d868c0906301147y1735de3eg6293f96d2c0bde4d@mail.gmail.com>

I'm getting a different failure in llvmc link on Leopard mac builds (Debug
and Release):
llvm[1]: Linking Release executable llvmc (without symbols)
g++ -DLLVMC_BUILTIN_PLUGIN_1=Base -DLLVMC_BUILTIN_PLUGIN_2=Clang
-I/Users/john/work/projects/comp/llvm-work/exp/build/llvm-check/include
-I/Users/john/work/projects/comp/llvm-work/exp/build/llvm-check/tools/llvmc/driver
-I/Users/john/work/projects/comp/llvm-work/llvm/include
-I/Users/john/work/projects/comp/llvm-work/llvm/tools/llvmc/driver  -D_DEBUG
 -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O3
 -fno-common  -Woverloaded-virtual -m32  -pedantic -Wno-long-long -Wall -W
-Wno-unused-parameter -Wwrite-strings  -lCompilerDriver -O3
 -L/Users/john/work/projects/comp/llvm-work/exp/build/llvm-check/Release/lib
-L/Users/john/work/projects/comp/llvm-work/exp/build/llvm-check/Release/lib
 -o
/Users/john/work/projects/comp/llvm-work/exp/build/llvm-check/Release/bin/llvmc
 /Users/john/work/projects/comp/llvm-work/exp/build/llvm-check/tools/llvmc/driver/Release/Main.o
-lplugin_llvmc_Base -lplugin_llvmc_Clang \
   -lpthread -lffi -lm
Undefined symbols:
  "llvmc::ForceLinkageClang()", referenced from:
      llvmc::ForceLinkage()      in Main.o
      _main in Main.o
  "llvmc::ForceLinkageBase()", referenced from:
      llvmc::ForceLinkage()      in Main.o
      _main in Main.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[1]: ***
[/Users/john/work/projects/comp/llvm-work/exp/build/llvm-check/Release/bin/llvmc]
Error 1
make: *** [all] Error 1


On Tue, Jun 30, 2009 at 12:29 PM, Nick Lewycky <nlewycky at google.com> wrote:

> I'm seeing this new build failure, starting some time yesterday on ARM:
>
> make[3]: Entering directory `/home/nlewycky/llvm/tools/llvmc/driver'
> llvm[3]: Linking Debug executable llvmc
>
> g++ -DLLVMC_BUILTIN_PLUGIN_1=Base -DLLVMC_BUILTIN_PLUGIN_2=Clang -I/home/nlewycky/llvm/include -I/home/nlewycky/llvm/tools/llvmc/driver  -D_DEBUG  -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -g -fPIC  -Woverloaded-virtual   -pedantic -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings  -lCompilerDriver -g  -Wl,-R -Wl,/home/nlewycky/llvm/Debug/bin -Wl,-export-dynamic -L/home/nlewycky/llvm/Debug/lib -L/home/nlewycky/llvm/Debug/lib  -o /home/nlewycky/llvm/Debug/bin/llvmc  /home/nlewycky/llvm/tools/llvmc/driver/Debug/Main.o -lplugin_llvmc_Base -lplugin_llvmc_Clang \
>            -lpthread -ldl -lm
>
> /usr/bin/ld: /home/nlewycky/llvm/Debug/bin/llvmc: hidden symbol `__sync_val_compare_and_swap_4' in /usr/lib/gcc/arm-linux-gnueabi/4.3.3/libgcc.a(linux-atomic.o) is referenced by DSO
> /usr/bin/ld: final link failed: Nonrepresentable section on output
> collect2: ld returned 1 exit status
> make[3]: *** [/home/nlewycky/llvm/Debug/bin/llvmc] Error 1
>
> This is with LLVM being built by the system compiler (GCC 4.3.3-10 Debian).
> I'm not sure what to make of this. Would it be due to the atomics used for
> mutexes?
>
> 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.llvm.org/pipermail/llvm-dev/attachments/20090630/0618f2f9/attachment.html>

From nlewycky at google.com  Tue Jun 30 12:02:25 2009
From: nlewycky at google.com (Nick Lewycky)
Date: Tue, 30 Jun 2009 12:02:25 -0700
Subject: [LLVMdev] build failure on ARM linux
In-Reply-To: <4A4A5C8A.1020103@redhat.com>
References: <fd63e6a40906301129j30b40665y13d13f71de3ce66e@mail.gmail.com> 
	<4A4A5C8A.1020103@redhat.com>
Message-ID: <fd63e6a40906301202p72b57e48jbcaaa7aee23b687@mail.gmail.com>

2009/6/30 Andrew Haley <aph at redhat.com>

> Nick Lewycky wrote:
> > I'm seeing this new build failure, starting some time yesterday on ARM:
> >
> > make[3]: Entering directory `/home/nlewycky/llvm/tools/llvmc/driver'
> > llvm[3]: Linking Debug executable llvmc
> > g++ -DLLVMC_BUILTIN_PLUGIN_1=Base -DLLVMC_BUILTIN_PLUGIN_2=Clang
> -I/home/nlewycky/llvm/include -I/home/nlewycky/llvm/tools/llvmc/driver
>  -D_DEBUG  -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -g
> -fPIC  -Woverloaded-virtual   -pedantic -Wno-long-long -Wall -W
> -Wno-unused-parameter -Wwrite-strings  -lCompilerDriver -g  -Wl,-R
> -Wl,/home/nlewycky/llvm/Debug/bin -Wl,-export-dynamic
> -L/home/nlewycky/llvm/Debug/lib -L/home/nlewycky/llvm/Debug/lib  -o
> /home/nlewycky/llvm/Debug/bin/llvmc
>  /home/nlewycky/llvm/tools/llvmc/driver/Debug/Main.o -lplugin_llvmc_Base
> -lplugin_llvmc_Clang \
> >            -lpthread -ldl -lm
> > /usr/bin/ld: /home/nlewycky/llvm/Debug/bin/llvmc: hidden symbol
> `__sync_val_compare_and_swap_4' in
> /usr/lib/gcc/arm-linux-gnueabi/4.3.3/libgcc.a(linux-atomic.o) is referenced
> by DSO
> > /usr/bin/ld: final link failed: Nonrepresentable section on output
> > collect2: ld returned 1 exit status
> > make[3]: *** [/home/nlewycky/llvm/Debug/bin/llvmc] Error 1
> >
> > This is with LLVM being built by the system compiler (GCC 4.3.3-10
> > Debian). I'm not sure what to make of this. Would it be due to the
> > atomics used for mutexes?
>
> Yes.  It's just a matter of defining __sync_val_compare_and_swap_4:
>
> http://gcc.gnu.org/svn/gcc/trunk/gcc/config/arm/linux-atomic.c
>

The program is supposed to define it? LLVM doesn't directly call
__sync_val_compare_and_swap_4, so either the system headers #define
something else to it or gcc lowers another call to that. In either case, why
is it declared HIDDEN?

Nick


>
> Andrew.
> _______________________________________________
> 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.llvm.org/pipermail/llvm-dev/attachments/20090630/c3faa29b/attachment.html>

From juanc.martinez.santos at gmail.com  Tue Jun 30 12:17:39 2009
From: juanc.martinez.santos at gmail.com (Juan Carlos Martinez Santos)
Date: Tue, 30 Jun 2009 15:17:39 -0400
Subject: [LLVMdev] Generatin code for an ARM-LINUX machine
In-Reply-To: <645d868c0906301032s187cbf1do2019e967a8b6310e@mail.gmail.com>
References: <d17b77a40906291409g11dac454pebca2253499df2e1@mail.gmail.com>
	<f88b89a50906291423t771f371fnccc1bab77c715155@mail.gmail.com>
	<d17b77a40906301018k4d3a9b01ud8a51d720c5154b8@mail.gmail.com>
	<645d868c0906301032s187cbf1do2019e967a8b6310e@mail.gmail.com>
Message-ID: <d17b77a40906301217u6edee896k3644bbdfe16dea80@mail.gmail.com>

Thanks John,

I just realized that I am not working on the same "branch" of LLVM. Looking
the latest or the newest version I saw the folder with the script, but I did
not see a README file.

I ran the script, and I get:

**********
chown: cannot access `/usr/local/codesourcery': No such file or directory
**********

Therefore my question is if the script depends on others folders (or files)
that maybe are not in the 2.5 version.

Thanks in advance,

Juan Carlos



On Tue, Jun 30, 2009 at 1:32 PM, John Mosby <ojomojo at gmail.com> wrote:

> llvm/utils/crosstool/ARM/build-install-linux.sh
>
>
> On Tue, Jun 30, 2009 at 11:18 AM, Juan Carlos Martinez Santos <
> juanc.martinez.santos at gmail.com> wrote:
>
>> Thanks Misha,
>>
>> However, I could not find the crosstool. Could you please check the name
>> of the script?
>>
>> Regards,
>>
>> Juan Carlos
>>
>>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>


-- 
Juan Carlos Martínez Santos
242 Foster Drive Apt H
Colonial Townhouse Apartments
Willimantic, CT 06226-1538
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090630/eb240b64/attachment.html>

From aph at redhat.com  Tue Jun 30 12:18:06 2009
From: aph at redhat.com (Andrew Haley)
Date: Tue, 30 Jun 2009 20:18:06 +0100
Subject: [LLVMdev] JIT allocates global data in function body memory
In-Reply-To: <D557CD2A-54B9-40BC-AA6C-4CB4880C5D17@apple.com>
References: <9a9942200906291741p366b5c23qa52180bbb071d908@mail.gmail.com>	<D188A28D-BA9C-4262-81BE-6CAB4BBCEBF7@apple.com>	<bb55930e0906301118i30c811cbtf5f870c26db97b62@mail.gmail.com>
	<D557CD2A-54B9-40BC-AA6C-4CB4880C5D17@apple.com>
Message-ID: <4A4A64EE.70006@redhat.com>

Dale Johannesen wrote:
> On Jun 30, 2009, at 11:18 AMPDT, Jeffrey Yasskin wrote:
> 
>> On Mon, Jun 29, 2009 at 5:50 PM, Dale Johannesen<dalej at apple.com>  
>> wrote:
>>> On Jun 29, 2009, at 5:41 PMPDT, Reid Kleckner wrote:
>>>
>>>> So I (think I) found a bug in the JIT:
>>>> http://llvm.org/bugs/show_bug.cgi?id=4483
>>>>
>>>> Basically, globals used by a function are allocated in the same  
>>>> buffer
>>>> as the first code that uses it.  However, when you free the machine
>>>> code, you also free the memory holding the global's data.  The  
>>>> address
>>>> is still in the GlobalValue map, so any other code using that global
>>>> will access freed memory, which will cause problems as soon as you
>>>> reallocate that memory for something else.
>>>>
>>>> I tracked down the commit that introduced the bug:
>>>> http://llvm.org/viewvc/llvm-project?view=rev&revision=54442
>>>>
>>>> It very nicely explains what it does, but not why it does it, which
>>>> I'd like to know before I change it.  I couldn't find the author
>>>> (johannes) on IRC so ssen told me to ask LLVMdev about this  
>>>> behavior.
>>> That's me (and I'm not on IRC because I like messages to be
>>> archived).  The reason everything needs to go in the same buffer is
>>> that we're JITting code on one machine, then sending it to another to
>>> be executed, and references from one buffer to another won't work in
>>> that environment.  So that model needs to continue to work.  If you
>>> want to generalize it so other models work as well, go ahead.
>> So, you're moving code across machines without running any relocations
>> on it? How can that work? Are you just assuming that everything winds
>> up at the same addresses? Or is everything PC-relative on your
>> platform, so all that matters is that globals and the code are in the
>> same relative positions?

I presume (hope, really) that we don't end up with code and data in the
same page.  From
Intel® 64 and IA-32 Architectures Optimization Reference Manual:
Assembly/Compiler Coding Rule 57. (H impact, L generality) Always put
code and data on separate pages.

Sorry, I guess you know this already.

Andrew.


From isanbard at gmail.com  Tue Jun 30 12:54:24 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Tue, 30 Jun 2009 12:54:24 -0700
Subject: [LLVMdev] modifying llc asm output
In-Reply-To: <001701c9f9ae$e727a2d0$b576e870$@net>
References: <000f01c9f998$28625d10$79271730$@net>
	<16e5fdf90906301015u1b31c689l389e703eb2e5db71@mail.gmail.com>
	<001701c9f9ae$e727a2d0$b576e870$@net>
Message-ID: <16e5fdf90906301254k48969c72hab172bd2ebf1dcac@mail.gmail.com>

On Tue, Jun 30, 2009 at 11:16 AM, Michael
Graumann<MichaelGraumann at gmx.net> wrote:
> Ok :-) und how can I add inlined assembly to the output?
>
If you're compiling this from C source code, use the "__asm__
__volatile__ ("isync");" syntax. If you're generating straight LLVM
IR, then I'm not entirely sure. You'll have to create some type of
CallInst instruction. See TreeToLLVM::EmitASM_EXPR() in the LLVM-GCC
gcc/llvm-convert.cpp file for an example of how it generates one of
these.

-bw


From dgregor at apple.com  Tue Jun 30 13:12:31 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Tue, 30 Jun 2009 13:12:31 -0700
Subject: [LLVMdev] cmake configured buildbot
In-Reply-To: <4A4A188C.4020301@zafena.se>
References: <4A4A188C.4020301@zafena.se>
Message-ID: <34CCB4FF-9C94-4602-AD28-0D1623492F78@apple.com>


On Jun 30, 2009, at 6:52 AM, Xerxes Rånby wrote:

> Greetings
>
> Im interested to setup an automated buildbod that can test the cmake
> buildsysten.
> I use cmake for ARM cross compilation so I would be interested if
> someone are running a cmake bot and if its build logs be observed  
> online?

I don't know of anyone doing this now.

> If not, are there an easy way to setup a llvm cmake buildbot that can
> test the cmake build infrastructure for each commit?


This would be *wonderful*.

   - Doug


From aph at redhat.com  Tue Jun 30 14:05:56 2009
From: aph at redhat.com (Andrew Haley)
Date: Tue, 30 Jun 2009 22:05:56 +0100
Subject: [LLVMdev] build failure on ARM linux
In-Reply-To: <fd63e6a40906301202p72b57e48jbcaaa7aee23b687@mail.gmail.com>
References: <fd63e6a40906301129j30b40665y13d13f71de3ce66e@mail.gmail.com>
	<4A4A5C8A.1020103@redhat.com>
	<fd63e6a40906301202p72b57e48jbcaaa7aee23b687@mail.gmail.com>
Message-ID: <4A4A7E34.5020000@redhat.com>

Nick Lewycky wrote:
> 2009/6/30 Andrew Haley <aph at redhat.com <mailto:aph at redhat.com>>
> 
>     Nick Lewycky wrote:
>     > I'm seeing this new build failure, starting some time yesterday on
>     ARM:
> 
>     Yes.  It's just a matter of defining __sync_val_compare_and_swap_4:
> 
>     http://gcc.gnu.org/svn/gcc/trunk/gcc/config/arm/linux-atomic.c
> 
> 
> The program is supposed to define it? LLVM doesn't directly call
> __sync_val_compare_and_swap_4, so either the system headers #define
> something else to it or gcc lowers another call to that.

gcc lowers atomic operations to that.  It's part of libgcc now.

> In either case, why is it declared HIDDEN?

I'm not sure.

Andrew.


From resistor at mac.com  Tue Jun 30 15:38:09 2009
From: resistor at mac.com (Owen Anderson)
Date: Tue, 30 Jun 2009 15:38:09 -0700
Subject: [LLVMdev] MAJOR API CHANGE:  LLVMContext
Message-ID: <D58A96BE-A226-4377-856F-9922C7792257@mac.com>

Notice of a major upcoming API change:  The static methods for  
constructing types and constants will be going away in the future.   
Instead, the global uniquing tables that lurk behind these APIs will  
be privatized within LLVMContext instances.

What this means for you:  Your client application will need to create  
an LLVMContext in main(), and pass it into a few APIs (the constructor  
for Module, for instance).  You can, in theory, have more than one  
LLVMContext as long as you never want Modules created under separate  
contexts to interact.

In the near term, I will be committing patches to do this conversion  
for the existing LLVM tools, including Clang and LLVM-GCC, which  
should provide examples for those following along at home.

--Owen


From rnk at mit.edu  Tue Jun 30 15:59:47 2009
From: rnk at mit.edu (Reid Kleckner)
Date: Tue, 30 Jun 2009 15:59:47 -0700
Subject: [LLVMdev] JIT allocates global data in function body memory
In-Reply-To: <4A4A64EE.70006@redhat.com>
References: <9a9942200906291741p366b5c23qa52180bbb071d908@mail.gmail.com> 
	<D188A28D-BA9C-4262-81BE-6CAB4BBCEBF7@apple.com>
	<bb55930e0906301118i30c811cbtf5f870c26db97b62@mail.gmail.com> 
	<D557CD2A-54B9-40BC-AA6C-4CB4880C5D17@apple.com>
	<4A4A64EE.70006@redhat.com>
Message-ID: <9a9942200906301559w422349bel1ccdd138509d7b68@mail.gmail.com>

> I presume (hope, really) that we don't end up with code and data in the
> same page.  From
> Intel® 64 and IA-32 Architectures Optimization Reference Manual:
> Assembly/Compiler Coding Rule 57. (H impact, L generality) Always put
> code and data on separate pages.

Hahaha, nope.  So this change could actually be a performance win!

Dale, here's a preliminary patch:
http://codereview.appspot.com/90053 (also attached)

Would this kind of change be acceptable to your mysterious client who
won't fully disclose their requirements?  All they have to do is flip
a static boolean flag (it's ugly, I know, but I wanted it to be easy
to change programmatically so a CLI flag takes more work).

Reid
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JITMemoryManager.diff
Type: text/x-diff
Size: 17805 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090630/25967afc/attachment.diff>

From resistor at mac.com  Tue Jun 30 17:14:03 2009
From: resistor at mac.com (Owen Anderson)
Date: Tue, 30 Jun 2009 17:14:03 -0700
Subject: [LLVMdev] MAJOR API CHANGE:  LLVMContext
In-Reply-To: <D58A96BE-A226-4377-856F-9922C7792257@mac.com>
References: <D58A96BE-A226-4377-856F-9922C7792257@mac.com>
Message-ID: <7927058E-742F-4B91-8F32-D2AED5EDA126@mac.com>

To ease this transition, I have added a getGlobalContext() API.  If  
you're only ever planning to use LLVM on a single thread, it will be  
completely safe to simply pass this value to every API that takes an  
LLVMContext.

--Owen

On Jun 30, 2009, at 3:38 PM, Owen Anderson wrote:

> Notice of a major upcoming API change:  The static methods for
> constructing types and constants will be going away in the future.
> Instead, the global uniquing tables that lurk behind these APIs will
> be privatized within LLVMContext instances.
>
> What this means for you:  Your client application will need to create
> an LLVMContext in main(), and pass it into a few APIs (the constructor
> for Module, for instance).  You can, in theory, have more than one
> LLVMContext as long as you never want Modules created under separate
> contexts to interact.
>
> In the near term, I will be committing patches to do this conversion
> for the existing LLVM tools, including Clang and LLVM-GCC, which
> should provide examples for those following along at home.
>
> --Owen
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



From samuraileumas at yahoo.com  Tue Jun 30 17:47:52 2009
From: samuraileumas at yahoo.com (Samuel Crow)
Date: Tue, 30 Jun 2009 17:47:52 -0700 (PDT)
Subject: [LLVMdev] MAJOR API CHANGE:  LLVMContext
In-Reply-To: <7927058E-742F-4B91-8F32-D2AED5EDA126@mac.com>
References: <D58A96BE-A226-4377-856F-9922C7792257@mac.com>
	<7927058E-742F-4B91-8F32-D2AED5EDA126@mac.com>
Message-ID: <492121.92081.qm@web62001.mail.re1.yahoo.com>


Hello Owen,

Is this effective immediately for the 2.6 Top of Tree or is it something that will change in the next release (eg. 2.7)?

Thanks,


--Sam


----- Original Message ----
> From: Owen Anderson <resistor at mac.com>
> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Sent: Tuesday, June 30, 2009 7:14:03 PM
> Subject: Re: [LLVMdev] MAJOR API CHANGE:  LLVMContext
> 
> To ease this transition, I have added a getGlobalContext() API.  If  
> you're only ever planning to use LLVM on a single thread, it will be  
> completely safe to simply pass this value to every API that takes an  
> LLVMContext.
> 
> --Owen
> 
> On Jun 30, 2009, at 3:38 PM, Owen Anderson wrote:
> 
> > Notice of a major upcoming API change:  The static methods for
> > constructing types and constants will be going away in the future.
> > Instead, the global uniquing tables that lurk behind these APIs will
> > be privatized within LLVMContext instances.
> >
> > What this means for you:  Your client application will need to create
> > an LLVMContext in main(), and pass it into a few APIs (the constructor
> > for Module, for instance).  You can, in theory, have more than one
> > LLVMContext as long as you never want Modules created under separate
> > contexts to interact.
> >
> > In the near term, I will be committing patches to do this conversion
> > for the existing LLVM tools, including Clang and LLVM-GCC, which
> > should provide examples for those following along at home.
> >
> > --Owen



      


From eli.friedman at gmail.com  Tue Jun 30 18:32:47 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Tue, 30 Jun 2009 18:32:47 -0700
Subject: [LLVMdev] MAJOR API CHANGE: LLVMContext
In-Reply-To: <492121.92081.qm@web62001.mail.re1.yahoo.com>
References: <D58A96BE-A226-4377-856F-9922C7792257@mac.com>
	<7927058E-742F-4B91-8F32-D2AED5EDA126@mac.com>
	<492121.92081.qm@web62001.mail.re1.yahoo.com>
Message-ID: <f5aa3e9b0906301832p36c72466h1cecedda7362054a@mail.gmail.com>

On Tue, Jun 30, 2009 at 5:47 PM, Samuel Crow<samuraileumas at yahoo.com> wrote:
> Is this effective immediately for the 2.6 Top of Tree or is it something that will change in the next release (eg. 2.7)?

The code freeze for 2.6 is still nearly two months away; it's safe to
assume any API changes are going to apply to current trunk (i.e. 2.6).

-Eli


From nicolas.geoffray at lip6.fr  Tue Jun 30 19:38:55 2009
From: nicolas.geoffray at lip6.fr (Nicolas Geoffray)
Date: Wed, 01 Jul 2009 04:38:55 +0200
Subject: [LLVMdev] MAJOR API CHANGE:  LLVMContext
In-Reply-To: <D58A96BE-A226-4377-856F-9922C7792257@mac.com>
References: <D58A96BE-A226-4377-856F-9922C7792257@mac.com>
Message-ID: <4A4ACC3F.8090501@lip6.fr>

That's awesome, thanks very much for working on this Owen. So if I 
understand correctly, there can be as many LLVMContext instances as we 
want? Or one module only has a single LLVMContext?

A similar question is: can I now delete constants created, after 
JIT-compiling a function's IR? I know we can already delete the body of 
the function, but not the constants the body needs. So can we do that now?

Thanks!
Nicolas

Owen Anderson wrote:
> Notice of a major upcoming API change:  The static methods for  
> constructing types and constants will be going away in the future.   
> Instead, the global uniquing tables that lurk behind these APIs will  
> be privatized within LLVMContext instances.
>
> What this means for you:  Your client application will need to create  
> an LLVMContext in main(), and pass it into a few APIs (the constructor  
> for Module, for instance).  You can, in theory, have more than one  
> LLVMContext as long as you never want Modules created under separate  
> contexts to interact.
>
> In the near term, I will be committing patches to do this conversion  
> for the existing LLVM tools, including Clang and LLVM-GCC, which  
> should provide examples for those following along at home.
>
> --Owen
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   



From linus_wind at zju.edu.cn  Tue Jun 30 20:21:37 2009
From: linus_wind at zju.edu.cn (Wenzhi Tao)
Date: Wed, 01 Jul 2009 11:21:37 +0800
Subject: [LLVMdev] Limitations of Alias Analysis?
In-Reply-To: <f5aa3e9b0906292035x5493322bk652870eff21e660b@mail.gmail.com>
References: <446261587.07109@zju.edu.cn> <4A487FF4.9060007@gmail.com>
	<446327839.30312@zju.edu.cn>
	<f5aa3e9b0906292035x5493322bk652870eff21e660b@mail.gmail.com>
Message-ID: <446416682.26656@zju.edu.cn>

Hi Eli,
  I'm using trunk LLVM:

SVN-URL: http://llvm.org/svn/llvm-project/llvm/trunk
Version: 74580

  The result of llvm-config --version is '2.6svn'.

  And, when I try the released version 2.5, it still reports that %0 and
%1 are MayAlias. I wonder why I can't get the same result with you.
Thank you.

在 2009-06-29一的 20:35 -0700，Eli Friedman写道：
> On Mon, Jun 29, 2009 at 7:40 PM, Wenzhi Tao<linus_wind at zju.edu.cn> wrote:
> >  The result of -aa-eval:
> >
> > MayAlias:   %struct.Location* %0, %struct.Location* %1
> > MayAlias:   %struct.Location* %0, %struct.Location* %2
> > MayAlias:   %struct.Location* %1, %struct.Location* %2
> 
> I'm getting NoAlias with the given steps; are you using trunk LLVM?
> 
> -Eli
> 
> 



From zhunansjtu at gmail.com  Tue Jun 30 20:23:34 2009
From: zhunansjtu at gmail.com (zhunan)
Date: Wed, 01 Jul 2009 11:23:34 +0800
Subject: [LLVMdev] BInary encode of LLVM's ISA?
Message-ID: <1246418614.9923.2.camel@UIUC>

Hi,all

Where may I find the binary encode of llvm's ISA?
I would like to load the instructions from llvm bitcode file and
translate it to another kind of ISA dinamically,but I searched all docs
in llvm.org,nothing has been found ,can anyone help me?

zhunan
2009.7.1



From daniel at zuster.org  Tue Jun 30 21:36:28 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Tue, 30 Jun 2009 21:36:28 -0700
Subject: [LLVMdev] Profiling in LLVM Patch
In-Reply-To: <4A48C2CC.4060708@student.tuwien.ac.at>
References: <4A48C2CC.4060708@student.tuwien.ac.at>
Message-ID: <6a8523d60906302136j37afe97etf7b99c2ab6b1c007@mail.gmail.com>

Hi Andreas,

First, thanks again for undertaking this work and submitting it back. There is a
lot of good stuff here and it would be great to see it get back into the tree.

I have a few major high-level comments on the patch. First off, the patch is
quite large and should be broken down into separate incremental changes which
are easier to review and apply. I think the patches should more or less
correspond to the these high-level issues:

1. The intent of ProfileInfo is that it is the public interface used by the rest
of LLVM for all "profiling" related analyses. As such, we want it to have a
thin, well-defined interface which can be implemented by multiple analysis
providers, just like we have with the current alias analysis interface. Your
current patch has a large number of changes to ProfileInfo which should instead
be inside a subclass of ProfileInfo, where most of the implementation details
are private.

I think the first task should be to separate out the changes which are
appropriate for the ProfileInfo class itself and apply those to the tree. I
believe that the important changes which are worth reflecting in the API are
changed the weights to return a double instead of an int, and defining -1 as a
sentinel, "don't know", value.

This is the most important thing to separate out, and to do early, because it is
the main interface that is shared with LLVM. It is also important for my GSoC
student, who was going to work on static profiling for LLVM and will depend on
any changes to this interface.

The current ProfileInfo functions should also become virtual, and all other
implementation details should be left to the subclass.

Finally, I don't think the ignoreMissing parameter to getExecutionCount makes
sense, instead the provider should always return -1 if it doesn't have the
value, and clients should "do the right thing.

2. We shouldn't worry too much about preserving the functionality of the current
llvm-prof tool, which uses the ProfileInfoLoader directly. llvm-prof should be
rewritten to just use the public API provided by ProfileInfo. This should be
done early so there are less dependencies on the ProfileInfoLoader interface.

In fact, it might even make sense to just get rid of llvm-prof and instead
implement a module level pass which consumes profiling information and prints it
out as part of the pass. This would allow us to debug the preservation of
profiling information once we start modifying optimization passes to update it.

3. The static profiling estimator should be implemented as just another
ProfileInfo implementation. I believe this can be a separate patch. Similarly
the profile verifier is just another consumer of ProfileInfo and can be a
separate patch.

4. Finally, the new optimal edge instrumentation & ProfileInfo implementation
can be brought in.

Does this sound like a reasonable plan? Although it is a bit of work, I don't
think it will be that difficult and I am happy to help out with splitting up the
patch / refactoring the existing code.

In addition, I have a number of "nitpicks" mostly related to LLVM style:
 - Please make comments complete sentences, including capitalizing the first
  word and trailing punctuation.

 - Please format function prototypes to have the arguments following the '(',
  and wrapped onto new lines as appropriate to fit in 80 columns. That is,
--
   static MaxSpanTree getMaxSpanTree(Function *F, ProfileInfo *PI,
                                     bool invert);
--
not
--
   static MaxSpanTree getMaxSpanTree(
       Function *F, ProfileInfo *PI, bool invert);
--

 - Please no spacing after the function in a call ("assert(" not "assert (") and
  no spacing inside if ("if (foo)" not "if ( foo )").

 - In general, get...() functions should be marked 'const' when possible.

Finally, I have some other technical comments inline with the diff below.

Thanks again for sharing your work!
 - Daniel

> +  /// getExitEdges - Return all pairs of (_inside_block_,_outside_block_).
> +  /// (Modelled after getExitingBlocks().)
> +  typedef std::pair<BlockT*,BlockT*> Edge;
> +  void getExitEdges(SmallVectorImpl<Edge> &ExitEdges) const {
> +    // Sort the blocks vector so that we can use binary search to do quick
> +    // lookups.
> +    SmallVector<BlockT*, 128> LoopBBs(block_begin(), block_end());
> +    std::sort(LoopBBs.begin(), LoopBBs.end());

Would it be better to use a DenseSet for this lookup?

> --- llvm-van/include/llvm/Analysis/MaximumSpanningTree.h      1970-01-01 01:00:00.000000000 +0100
> +++ llvm-c7/include/llvm/Analysis/MaximumSpanningTree.h       2009-06-26 16:47:01.000000000 +0200
...
> +#include "llvm/Support/Streams.h"

Please don't use Support/Streams.h in a header, it pollutes any translation unit
which imports this header.

> +    static void print(MaxSpanTree MST) {
> +      cerr<<"{";
> +      for ( MaxSpanTree::iterator ei = MST.begin(), ee = MST.end();
> +            ei!=ee; ++ei ) {
> +        cerr<<"("<<((*ei).first?(*ei).first->getName():"0")<<",";
> +        cerr<<(*ei).second->getName()<<")";
> +      }
> +      cerr<<"}\n";
> +    }
> +  };

To be more in line with LLVM I would recommend making this a nullary const
method on the MST, and rename it to dump. Also, please use Support/raw_ostream.h
for output instead of C++ iostreams.

> --- llvm-van/include/llvm/Analysis/Passes.h   2009-06-29 13:49:13.000000000 +0200
> +++ llvm-c7/include/llvm/Analysis/Passes.h    2009-06-26 16:48:02.000000000 +0200
>    // createProfileLoaderPass - This pass loads information from a profile dump
> -  // file.
> +  // file. Since its possible to use the ProfileInfoLoaderPass not only from
> +  // opt but also e.g. from llvm-prof and with different profile info filenames
> +  // a creator is provided where the toolname and profile info filename can be
> +  // provided. (The toolname is used to create proper error messages.)
>    //
>    ModulePass *createProfileLoaderPass();
> +  ModulePass *createProfileLoaderPass(const std::string &, const std::string &);

Please name the arguments so it is clear which is the toolname and which is the
profile info name (bonus points for switching to doxygen comments which
reference the parameters).

> --- llvm-van/include/llvm/Analysis/ProfileInfo.h      2009-05-12 10:37:52.000000000 +0200
> +++ llvm-c7/include/llvm/Analysis/ProfileInfo.h       2009-06-26 16:47:01.000000000 +0200

Keep in mind that most comments here are assuming this functionality is moved to
a subclass specific to optimal edge profiling.

>    protected:
> -    // EdgeCounts - Count the number of times a transition between two blocks is
> -    // executed.  As a special case, we also hold an edge from the null
> -    // BasicBlock to the entry block to indicate how many times the function was
> -    // entered.
> -    std::map<std::pair<BasicBlock*, BasicBlock*>, unsigned> EdgeCounts;
> +    // EdgeInformation - Count the number of times a transition between two
> +    // blocks is executed.  As a special case, we also hold an edge from the
> +    // null BasicBlock to the entry block (henceforth (0,entry) to indicate
> +    // how many times the function was entered. (This is especially necessary
> +    // if there is only the entry block.)
> +    std::map<Function*, EdgeCounts> EdgeInformation;
> +
> +    // BlockInformation - Count the number of times a block is executed
> +    std::map<Function*, BlockCounts> BlockInformation;
> +
> +    // FunctionInformation - Count the number of times a function is executed
> +    std::map<Function*, double> FunctionInformation;

Instead of multiple maps from Function* ->, would it make sense to collect these
three (or four) maps inside a per-function structure?

> +    // getFunctionForEdge() - This returns the Function for a given Edge. This
> +    // requires special handling for (0,entry) so its centralised here.
> +    static inline Function* getFunctionForEdge(Edge E) {
> +      BasicBlock *BB = E.first;
> +      if ( BB == 0 ) { BB = E.second; };
> +      assert ( BB != 0 && "both BasicBlocks of Edge are NULL, can not "
> +                          "determine function");
> +      return BB->getParent();
> +    }

The edge destination should always be non-null, correct? Why not just
--
   static inline Function* getFunctionForEdge(Edge E) {
     assert(E.second && "Invalid profile edge!");
     return E.second->getParent();
   }
--

> +    // getFunctionForBlock() - Same as for Edges without special handling, for
> +    // the sake of cleaner code.
> +    static inline Function* getFunctionForBlock(BasicBlock* BB) {
> +      return BB->getParent();
> +    }

I would prefer this wasn't used, its "common knowledge" in the LLVM code that a
basic blocks parent is its Function.

> +    EdgeCounts getEdgeCounts(Function *F) {
> +      std::map<Function*, EdgeCounts>::const_iterator J =
> +        EdgeInformation.find(F);
> +      if ( J != EdgeInformation.end() ) {
> +        return J->second;
> +      }
> +      return EdgeCounts(); // Return empty EdgeCounts in case none found.
> +    }

This is way too expensive, returning a deep copy of the edge counts map isn't
necessary. The simplest alternative is to return a const reference and insert
into the map for missing functions. Something like:
--
> +    const EdgeCounts& getEdgeCounts(Function *F) {
> +      return EdgeInformation[F];
> +    }
--
Unless we really care about not inserting empty entries this seems reasonable to
me.

> +    void forceSynthesis(void) {
> +      for (std::map<Function*, EdgeCounts>::iterator
> +           FI = EdgeInformation.begin(), FIE = EdgeInformation.end();
> +           FI != FIE; ++FI) {
> +        Function *F = FI->first;
> +        for (Function::iterator BB = F->begin(), BBE = F->end();
> +             BB != BBE; ++BB) {
> +          getExecutionCount(BB,false);
> +        }
> +        getExecutionCount(F,false);
> +      }
> +    }

It doesn't make sense to have this function here, clients should just do the
right thing if the count isn't present. It may be worth providing a ProfileInfo
level API to query whether any information is present for a particular function
so that clients don't perform needless queries.

> --- llvm-van/lib/Analysis/MaximumSpanningTree.cpp     1970-01-01 01:00:00.000000000 +0100
> +++ llvm-c7/lib/Analysis/MaximumSpanningTree.cpp      2009-06-26 16:47:01.000000000 +0200
...
> +#define WOOD_REP(M,V1,V2) \

Please use "forest" instead of "wood".

> +  // compare two weighted edges
> +  struct VISIBILITY_HIDDEN EdgeWeightCompare {
> +    bool operator()(const ProfileInfo::EdgeWeight X,
> +                    const ProfileInfo::EdgeWeight Y) const {
> +      if ( X.second > Y.second ) return true;
> +      if ( X.second < Y.second ) return false;
> +      if ( X.first.first != 0 && Y.first.first == 0 ) return true;
> +      if ( X.first.first == 0 && Y.first.first != 0 ) return false;
> +      if ( X.first.first == 0 && Y.first.first == 0 ) return false;
> +      int c1 =  X.first.first->getName().compare(Y.first.first->getName());
> +      if ( c1 > 0 ) return true;
> +      if ( c1 < 0 ) return false;
> +      int c2 =  X.first.second->getName().compare(Y.first.second->getName());
> +      if ( c2 > 0 ) return true;
> +      return false;
> +    }
> +  };

Comparing edges based on the basic block name is not a good idea, in some common
cases these will all be empty. If the ordering really needs to be deterministic
then you will need to number the basic blocks, but is there a compelling reason
to not order based on the basic block address?

Regardless, I think this can be simplified to:
> +  struct VISIBILITY_HIDDEN EdgeWeightCompare {
> +    bool operator()(const ProfileInfo::EdgeWeight X,
> +                    const ProfileInfo::EdgeWeight Y) const {
> +      if ( X.second != Y.second ) return (X.second > Y.second);
> +      if ( X.first.first != Y.first.first ) return (X.first.first > Y.first.first);
> +      return (X.first.second > Y.first.second);
> +    }
> +  };
using a helper routine for comparing the basic blocks if necessary (to handle
the null case).

> +// countSuccessors() - This gives an estimate of the number of successors of a
> +// basic block. Returns 0, 1 or 2 depending on the block having no, one or more
> +// than one successors respectively.
> +static int countSuccessors(BasicBlock* BB) {
> +  succ_iterator SI = succ_begin(BB), SE = succ_end(BB);
> +  if ( SI != SE ) {       // at least one successor
> +    ++SI;
> +    if ( SI == SE ) {     // exactly on successor
> +      return 1;
> +    } else {              // more than one successor
> +      return 2;
> +    }
> +  } else {
> +    return 0;
> +  }
> +}

This routine is only used in one place, and its result is compared against 0. I
think it should be removed and the code should just check (succ_begin(BB) ==
succ_end(BB)), or for better readability add a succ_empty to CFG.h and use that.

> --- llvm-van/lib/Analysis/ProfileEstimatorPass.cpp    1970-01-01 01:00:00.000000000 +0100
> +++ llvm-c7/lib/Analysis/ProfileEstimatorPass.cpp     2009-06-26 16:47:01.000000000 +0200
...
> +bool OptimalEdgeProfiler::runOnModule(Module &M) {
> +  Function *Main = M.getFunction("main");
> +  if (Main == 0) {
> +    cerr << "WARNING: cannot insert edge profiling into a module"
> +         << " with no main function!\n";
> +    return false;  // No main, no instrumentation!
> +  }
> +
> +  std::set<BasicBlock*> BlocksToInstrument;
> +  unsigned NumEdges = 0;
> +  for (Module::iterator F = M.begin(), E = M.end(); F != E; ++F) {
> +    if (F->isDeclaration()) continue;
> +    // use one counter for the edge (0,entry) for each function
> +    ++NumEdges;
> +    for (Function::iterator BB = F->begin(), E = F->end(); BB != E; ++BB) {
> +      // Keep track of which blocks need to be instrumented.  We don't want to
> +      // instrument blocks that are added as the result of breaking critical
> +      // edges!
> +      BlocksToInstrument.insert(BB);
> +      NumEdges += BB->getTerminator()->getNumSuccessors();
> +    }
> +  }
> +
> +  const ArrayType *ATy = ArrayType::get(Type::Int32Ty, NumEdges);
> +  GlobalVariable *Counters =
> +    new GlobalVariable(ATy, false, GlobalValue::InternalLinkage,
> +                       0, "OptimalEdgeProfCounters", &M);
> +
> +  std::vector<Constant*> Initializer = std::vector<Constant*>(NumEdges);

This unnecessarily copies the vector, please use:
 std::vector<Constant*> Initializer(NumEdges);

> +  APInt zero(32,0);      Constant* zeroc = ConstantInt::get(zero);
> +  APInt minusone(32,-1); Constant* minusonec = ConstantInt::get(minusone);

Please use:
> +  Constant* zeroc = ConstantInt::get(llvm::Type::Int32Ty, 0);
> +  Constant* onec = ConstantInt::getSigned(llvm::Type::Int32Ty, -1);

On Mon, Jun 29, 2009 at 6:34 AM, Andreas
Neustifter<e0325716 at student.tuwien.ac.at> wrote:
> Hi all,
>
> as proposed in
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-February/020396.html
> I implemented the algorithm presented in [Ball94]. It only instruments
> the minimal number of edges necessary for edge profiling.
>
> The main changes introduced by this patch are:
> *) a interface compatible rewrite of ProfileInfo
> *) a cleanup of ProfileInfoLoader
>   (some functionality in ProfileInfoLoader was duplicated in ProfileInfo or
>   ProfileInfoLoaderPass; ProfileInfoLoader now really only performs the
>   loading but not the post-processing)
> *) a new instrumentation pass that performs the optimal edge profiling
>   instrumentation
> *) a helper module MaximumSpanningTree that selects the edges with have to
>   be instrumented for optimal edge profiling
> *) a ProfileEstimatorPass that does an offline estimation of a profile based
>   on branching and loop depth (also proposed in [Ball94])
>   (it is possible to use this ProfileEstimator stand-alone to have at least
>   some profile estimation available in the frontend without doing profiling
>   runs)
> *) a ProfileVerifierPass that checks the current profiling information
>   against the flow preservation rules
>
> I did performance measurements on the C and C++ portions of the SPEC CPU2000
> benchmark, the results are:
> *) on average 46% of the edges are instrumented with a counter (in
>   comparison to 100% with the current edge profiling)
> *) the performance overhead (on linux-x68_64, other platforms to follow) was
>   14.76% with the current profiling and 8.20% with the optimal profiling
>   (there are strange effects with the mcf and equake benchmarks where the
>   current edge profiling is as fast as the un-instrumented code whereas the
>   optimally instrumented code has a small (~5%) performance overhead)
> *) when mcf and equake are excluded the average performance overhead is
>   51.31% with optimal profiling (in comparison to 100% with the current
>   edge profiling)
>
> Please tell me what you do not like and if this is interesting enough to be
> added to the trunk, if so, I will also devise test cases for "make check".
>
> If you do not like the size of this patch it is possible to break it up a
> little. I did not use the mkpatch utility since it does not include added
> files, I hope the format is readable enough (it should be...)
>
> I ran "make check" and there are not additional errors introduced
> by the patch.
>
> Grettings,
>
> Andreas Neustifter
>
> [Ball94] Thomas Ball, James R. Larus:
> "Optimally profiling and tracing programs"
> ACM TOPLAS, Volume 16, Issue 4, 1994
> http://portal.acm.org/citation.cfm?id=183527
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>



From sanjiv.gupta at microchip.com  Tue Jun 30 23:35:23 2009
From: sanjiv.gupta at microchip.com (Sanjiv Gupta)
Date: Wed, 01 Jul 2009 12:05:23 +0530
Subject: [LLVMdev] llvmc for PIC16
In-Reply-To: <3cb898890906291950t4e670f35w953103e7080a62e6@mail.gmail.com>
References: <4A2633E9.4070207@microchip.com> <4A35EA76.7090602@microchip.com>	
	<3cb898890906150348l2e0d4095seb54de38f95e69f9@mail.gmail.com>	
	<4A3656A3.1050403@microchip.com>	
	<3cb898890906150730k534167dfxf59677e966477220@mail.gmail.com>	
	<4A39F1D7.4060101@microchip.com>	
	<3cb898890906180430k5cb0d57fh7c66d10a45c50db0@mail.gmail.com>	
	<4A48ED9A.2040403@microchip.com>	
	<3cb898890906291902t1e965aa9h6df1f325684b5f47@mail.gmail.com>	
	<4A497B39.1010709@microchip.com>
	<3cb898890906291950t4e670f35w953103e7080a62e6@mail.gmail.com>
Message-ID: <4A4B03AB.2030206@microchip.com>

The driver behaves differently when I run it by specifying absolute path 
than when I run it with relative path.
See example

Relative:

i00202 at ubuntu:/tmp$ mcc16 --save-temps -dry-run  hello.c./clang-cc -I 
./include -triple=pic16- -emit-llvm-bc hello.c -o hello.bc-pqDR1Y
llvm-ld -link-as-library hello.bc-pqDR1Y -o tmp.bc-M1Rwip
llc -march=pic16 -f tmp.bc-M1Rwip -o tmp.s-DcVczP
gpasm -I ./inc tmp.s-DcVczP -o tmp.o
mplink /k ./lkr /l ./lkr tmp.o -o a.out

Absolute:

i00202 at ubuntu:/tmp$ /home/i00202/projects/llvm/Debug/bin/mcc16 
--save-temps -dry-run  hello.c
/home/i00202/projects/llvm/Debug/bin/clang-cc -I 
/home/i00202/projects/llvm/Debug/include -triple=pic16- -emit-llvm-bc 
hello.c -o hello.bc-iqtUNP
llvm-ld -link-as-library hello.bc-iqtUNP -o tmp.bc-6pjc0L
llc -march=pic16 -f tmp.bc-6pjc0L -o tmp.s-RYXucI
gpasm -I /home/i00202/projects/llvm/Debug/inc tmp.s-RYXucI -o tmp.o
mplink /k /home/i00202/projects/llvm/Debug/lkr /l 
/home/i00202/projects/llvm/Debug/lkr tmp.o -o a.out



With absolute path it is able to find my headers, libs correctly but not 
with relative.
While debugging with ddd, the ddd always printed full paths for headers etc.

- Sanjiv