Gurumurthy, Sujatha
2011-Feb-23 01:21 UTC
[LLVMdev] LLVMdev Digest, Vol 80, Issue 37-Help to unsubscribe
Please unsubscribe me from this list.
Sujatha Gurumurthy
Staffing Consultant/Talent Advisor
UMG - Ultra Mobile Group
sujatha.gurumurthy at intel.com
US ERP Manager
Interested in Employee Referral Program
Visit referral.intel.com/
Intel USA Employee Referral Program Group
100 Best Companies to Work For 2011: Intel - INTC - from FORTUNE
-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of llvmdev-request at cs.uiuc.edu
Sent: Tuesday, February 22, 2011 4:47 PM
To: llvmdev at cs.uiuc.edu
Subject: LLVMdev Digest, Vol 80, Issue 37
Send LLVMdev mailing list submissions to
llvmdev at cs.uiuc.edu
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
or, via email, send a message with subject or body 'help' to
llvmdev-request at cs.uiuc.edu
You can reach the person managing the list at
llvmdev-owner at cs.uiuc.edu
When replying, please edit your Subject line so it is more specific
than "Re: Contents of LLVMdev digest..."
Today's Topics:
1. Re: attaching metadata to llvm::Argument (Andrew Clinton)
2. Re: STM8 backend for Clang (Andreas F?rber)
3. Clone a function and change signature (Arushi Aggarwal)
4. Re: Clone a function and change signature (John Criswell)
5. Re: Structure Types and ABI sizes (David A. Greene)
6. Re: still failed to build the llbrowse on Debian5-32b-llvm2.8
(Talin)
7. repo.or.cz GIT mirrors (Anton Korobeynikov)
8. Re: Questions about LLVM IR encoding (David A. Greene)
9. Re: Clone a function and change signature (Chris Lattner)
10. Re: Question about Value Range Propagation (Chris Lattner)
11. Re: unary floating point operations using clang (Chris Lattner)
12. Re: Question about Value Range Propagation (John Criswell)
13. Re: still failed to build the llbrowse on Debian5-32b-llvm2.8
(Chuck Zhao)
14. duplicate .debug_line sections (Dineth)
15. Re: duplicate .debug_line sections (Devang Patel)
16. obtain the address and size of LLVM generated temporaries
(Chuck Zhao)
17. Re: obtain the address and size of LLVM generated temporaries
(Yuri)
18. Re: Structure Types and ABI sizes (Jochen Wilhelmy)
19. virtual register does not exist (drizzle drizzle)
20. Re: Looking for more LLBrowse testers / users (John Myers)
21. Re: virtual register does not exist (Jakob Stoklund Olesen)
22. Re: Can I use Clang to parse snippets of C++ code?
(F?lix Cloutier)
----------------------------------------------------------------------
Message: 1
Date: Tue, 22 Feb 2011 13:00:24 -0500
From: Andrew Clinton <andrew at sidefx.com>
Subject: Re: [LLVMdev] attaching metadata to llvm::Argument
To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
Message-ID: <4D63F9B8.9070305 at sidefx.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
The reason that I need this is that I'm supporting runtime function
specialization, where the arguments have known default values. When the
function is specialized, I need to replace uses of the argument with the
default value. I could not find any other way to store the metadata for
the default values other than to use module-level data. Does anyone
know a better way to accomplish this in the LLVM IR?
On 02/22/2011 12:41 PM, Andrew Clinton wrote:> I too would have an immediate application if metadata could be attached
> to arguments. I'm currently working around it by using named metadata
> in the module (matched by index to the arguments).
>
> Andrew
>
> On 02/21/2011 11:18 AM, Florian Merz wrote:
>> Hey everyone,
>>
>> I'm trying to retrieve information about signed-/unsignedness of an
>> llvm::Argument so I can print out it's value to the user properly.
llvm itself
>> doesn't distinguish signed and unsigned and so llvm::Type is of no
help here.
>> Checking for nsw/usw is only an unreliable approximation and only
available
>> for llvm::Instructions anyways.
>>
>> I tried to use debugging information (llvm::DIType) for this, but
>> getMetadata() is not available for llvm::Argument, only for
llvm::Instruction.
>>
>> Is there any other way to get at this information?
>>
>> Regards,
>> Florian
>> _______________________________________________
>> 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
------------------------------
Message: 2
Date: Tue, 22 Feb 2011 19:59:52 +0100
From: Andreas F?rber <andreas.faerber at web.de>
Subject: Re: [LLVMdev] STM8 backend for Clang
To: Eli Friedman <eli.friedman at gmail.com>
Cc: llvmdev at cs.uiuc.edu
Message-ID: <F4910078-E330-41A2-A68D-B806D2585D6F at web.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Am 21.02.2011 um 02:44 schrieb Eli Friedman:
> On Sun, Feb 20, 2011 at 4:23 PM, Andreas F?rber <andreas.faerber at
web.de
> > wrote:
>> The first issue I stumbled upon was that the Program Counter register
>> is 24 bits. [...]
>
> [...] if the only
> 24-bit register is the program counter, you could probably get away
> with pretending it's a 32-bit register.
>
>> Further, as pointer width I chose 16 bits since there currently seems
>> to be no way to distinguish between near and far pointers?
>
> LLVM doesn't support distinguishing between near and far pointers.
> Depending on how much work you want to put in and what exactly you're
> trying to build, you might be able to get away with just pretending
> all pointers are near and implementing __builtin_stm8_far_loadn() and
> __builtin_stm8_far_storen() intrinsics, though.
The example C code uses far pointers, e.g., to set up interrupt vectors:
typedef void @far (*interrupt_handler_t)(void);
struct interrupt_vector
{
unsigned char interrupt_instruction;
interrupt_handler_t interrupt_handler;
};
So I do need support for 24-bit pointers in the Clang frontend, in
order for the struct to fill four bytes here.
Not sure how intrinsics could help there. I assume that @far is a non-
standard keyword. Is it possible to derive a new language standard
similar to GCC's --std=gnu99 to handle such extensions? The only guide
I could find was on how to add an attribute...
Andreas
------------------------------
Message: 3
Date: Tue, 22 Feb 2011 13:31:55 -0600
From: Arushi Aggarwal <arushi987 at gmail.com>
Subject: [LLVMdev] Clone a function and change signature
To: llvmdev at cs.uiuc.edu
Message-ID:
<AANLkTinAsp-PiP0BjEDR9439-bSuGctSC4E9E5n+9nk1 at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
I want to clone a given function, and add an argument to it. I then want to
add a call to that new function. I have a callInstruction CI, which I want
to transform to call this new function, and to take a new argument.
The code I added was as follows
CI->getCalledFunction()->dump();
Function* DirectF = CloneFunction(CI->getCalledFunction());
DirectF->setName(CI->getCalledFunction()->getNameStr() +
"_SPEC");
DirectF->setLinkage(GlobalValue::InternalLinkage);
// add the extra argument
new
Argument(GEP->getPointerOperand()->getType(),"arg",DirectF);
M.getFunctionList().push_back(DirectF);
DirectF->dump();
SmallVector<Value*, 8> Args;
for(unsigned j =1;j<CI->getNumOperands();j++) {
Args.push_back(CI->getOperand(j));
}
//Add the extra parameter
Args.push_back(GEP->getPointerOperand());
CallInst *CallI = CallInst::Create(DirectF,Args.begin(),
Args.end(),"", CI);
CallI->dump();
But I get the following exception
call void @point_DIRECT(i16* %tmp1324mod, i16* %tmp1322mod) nounwind
define internal void @point_DIRECT(i16* %x, i16* %y) nounwind {
entry:
%xx = alloca i32 ; <i32*> [#uses=3]
%yy = alloca i32 ; <i32*> [#uses=3]
%tmp = load %struct.MT** @mt, align 8, !dbg !1018 ; <%struct.MT*>
[#uses=1]
%tmp1 = icmp eq %struct.MT* %tmp, null, !dbg !1018 ; <i1> [#uses=1]
br i1 %tmp1, label %return, label %bb, !dbg !1018
bb: ; preds = %entry
%tmp2 = load i16* %x, align 2, !dbg !1023 ; <i16> [#uses=1]
%tmp3 = sext i16 %tmp2 to i32, !dbg !1023 ; <i32> [#uses=1]
store i32 %tmp3, i32* %xx, align 4, !dbg !1023
%tmp4 = load i16* %y, align 2, !dbg !1024 ; <i16> [#uses=1]
%tmp5 = sext i16 %tmp4 to i32, !dbg !1024 ; <i32> [#uses=1]
store i32 %tmp5, i32* %yy, align 4, !dbg !1024
%tmp6 = load %struct.MT** @mt, align 8, !dbg !1025 ; <%struct.MT*>
[#uses=1]
call void @MTPoint_DIRECT(%struct.MT* %tmp6, i32* %xx, i32* %yy) nounwind
%tmp8 = load i32* %xx, align 4, !dbg !1026 ; <i32> [#uses=1]
%tmp9 = trunc i32 %tmp8 to i16, !dbg !1026 ; <i16> [#uses=1]
store i16 %tmp9, i16* %x, align 2, !dbg !1026
%tmp10 = load i32* %yy, align 4, !dbg !1027 ; <i32> [#uses=1]
%tmp11 = trunc i32 %tmp10 to i16, !dbg !1027 ; <i16> [#uses=1]
store i16 %tmp11, i16* %y, align 2, !dbg !1027
ret void
return: ; preds = %entry
ret void
}
define internal void @point_DIRECT_SPEC(i16* %x, i16* %y, %struct.termbox*
%arg) nounwind {
entry:
%xx = alloca i32 ; <i32*> [#uses=3]
%yy = alloca i32 ; <i32*> [#uses=3]
%tmp = load %struct.MT** @mt, align 8, !dbg !1018 ; <%struct.MT*>
[#uses=1]
%tmp1 = icmp eq %struct.MT* %tmp, null, !dbg !1018 ; <i1> [#uses=1]
br i1 %tmp1, label %return, label %bb, !dbg !1018
bb: ; preds = %entry
%tmp2 = load i16* %x, align 2, !dbg !1023 ; <i16> [#uses=1]
%tmp3 = sext i16 %tmp2 to i32, !dbg !1023 ; <i32> [#uses=1]
store i32 %tmp3, i32* %xx, align 4, !dbg !1023
%tmp4 = load i16* %y, align 2, !dbg !1024 ; <i16> [#uses=1]
%tmp5 = sext i16 %tmp4 to i32, !dbg !1024 ; <i32> [#uses=1]
store i32 %tmp5, i32* %yy, align 4, !dbg !1024
%tmp6 = load %struct.MT** @mt, align 8, !dbg !1025 ; <%struct.MT*>
[#uses=1]
call void @MTPoint_DIRECT(%struct.MT* %tmp6, i32* %xx, i32* %yy) nounwind
%tmp8 = load i32* %xx, align 4, !dbg !1026 ; <i32> [#uses=1]
%tmp9 = trunc i32 %tmp8 to i16, !dbg !1026 ; <i16> [#uses=1]
store i16 %tmp9, i16* %x, align 2, !dbg !1026
%tmp10 = load i32* %yy, align 4, !dbg !1027 ; <i32> [#uses=1]
%tmp11 = trunc i32 %tmp10 to i16, !dbg !1027 ; <i16> [#uses=1]
store i16 %tmp11, i16* %y, align 2, !dbg !1027
ret void
return: ; preds = %entry
ret void
}
opt: /home/vadve/aggarwa4/llvm27/llvm-2.7/lib/VMCore/Instructions.cpp:307:
void llvm::CallInst::init(llvm::Value*, llvm::Value* const*, unsigned int):
Assertion `(NumParams == FTy->getNumParams() || (FTy->isVarArg()
&&
NumParams > FTy->getNumParams())) && "Calling a function with
bad
signature!"' failed.
When I looked at the excption, it occurs when creating the CallInst.
The type of the function being called at that point is still the old type,
without the extra parameter, though the extra parameter seems to have been
added when I dump DirectF.
Can I get any pointers to what I am doing wrong, and what might be a
potential solution.
Thanks,
Arushi
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110222/618028cf/attachment-0001.html
------------------------------
Message: 4
Date: Tue, 22 Feb 2011 13:46:45 -0600
From: John Criswell <criswell at illinois.edu>
Subject: Re: [LLVMdev] Clone a function and change signature
To: Arushi Aggarwal <arushi987 at gmail.com>
Cc: "llvmdev at cs.uiuc.edu" <llvmdev at cs.uiuc.edu>
Message-ID: <4D6412A5.1030300 at illinois.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
On 2/22/11 1:31 PM, Arushi Aggarwal wrote:> Hi,
>
> I want to clone a given function, and add an argument to it. I then
> want to add a call to that new function. I have a callInstruction CI,
> which I want to transform to call this new function, and to take a new
> argument.
If I understand correctly, you're cloning the function first and then
adding a new argument to the clone. Do I understand correctly?
If so, I don't believe you can do that. IIRC, you have to first create
a new, empty function with the additional argument and then use
CloneFunctionInto() to clone the body of the original function into the
new function. I believe that's what poolalloc does and what I did the
last time I had to add function arguments to a function.
-- John T.
>
> The code I added was as follows
>
> CI->getCalledFunction()->dump();
> Function* DirectF = CloneFunction(CI->getCalledFunction());
> DirectF->setName(CI->getCalledFunction()->getNameStr() +
"_SPEC");
> DirectF->setLinkage(GlobalValue::InternalLinkage);
> // add the extra argument
> new
Argument(GEP->getPointerOperand()->getType(),"arg",DirectF);
> M.getFunctionList().push_back(DirectF);
> DirectF->dump();
>
> SmallVector<Value*, 8> Args;
> for(unsigned j =1;j<CI->getNumOperands();j++) {
> Args.push_back(CI->getOperand(j));
> }
> //Add the extra parameter
> Args.push_back(GEP->getPointerOperand());
> CallInst *CallI = CallInst::Create(DirectF,Args.begin(),
> Args.end(),"", CI);
> CallI->dump();
>
>
> But I get the following exception
>
> call void @point_DIRECT(i16* %tmp1324mod, i16* %tmp1322mod) nounwind
>
> define internal void @point_DIRECT(i16* %x, i16* %y) nounwind {
> entry:
> %xx = alloca i32 ; <i32*> [#uses=3]
> %yy = alloca i32 ; <i32*> [#uses=3]
> %tmp = load %struct.MT** @mt, align 8, !dbg !1018 ; <%struct.MT*>
> [#uses=1]
> %tmp1 = icmp eq %struct.MT* %tmp, null, !dbg !1018 ; <i1> [#uses=1]
> br i1 %tmp1, label %return, label %bb, !dbg !1018
>
> bb: ; preds = %entry
> %tmp2 = load i16* %x, align 2, !dbg !1023 ; <i16> [#uses=1]
> %tmp3 = sext i16 %tmp2 to i32, !dbg !1023 ; <i32> [#uses=1]
> store i32 %tmp3, i32* %xx, align 4, !dbg !1023
> %tmp4 = load i16* %y, align 2, !dbg !1024 ; <i16> [#uses=1]
> %tmp5 = sext i16 %tmp4 to i32, !dbg !1024 ; <i32> [#uses=1]
> store i32 %tmp5, i32* %yy, align 4, !dbg !1024
> %tmp6 = load %struct.MT** @mt, align 8, !dbg !1025 ; <%struct.MT*>
> [#uses=1]
> call void @MTPoint_DIRECT(%struct.MT* %tmp6, i32* %xx, i32* %yy)
> nounwind
> %tmp8 = load i32* %xx, align 4, !dbg !1026 ; <i32> [#uses=1]
> %tmp9 = trunc i32 %tmp8 to i16, !dbg !1026 ; <i16> [#uses=1]
> store i16 %tmp9, i16* %x, align 2, !dbg !1026
> %tmp10 = load i32* %yy, align 4, !dbg !1027 ; <i32> [#uses=1]
> %tmp11 = trunc i32 %tmp10 to i16, !dbg !1027 ; <i16> [#uses=1]
> store i16 %tmp11, i16* %y, align 2, !dbg !1027
> ret void
>
> return: ; preds = %entry
> ret void
> }
>
>
> define internal void @point_DIRECT_SPEC(i16* %x, i16* %y,
> %struct.termbox* %arg) nounwind {
> entry:
> %xx = alloca i32 ; <i32*> [#uses=3]
> %yy = alloca i32 ; <i32*> [#uses=3]
> %tmp = load %struct.MT** @mt, align 8, !dbg !1018 ; <%struct.MT*>
> [#uses=1]
> %tmp1 = icmp eq %struct.MT* %tmp, null, !dbg !1018 ; <i1> [#uses=1]
> br i1 %tmp1, label %return, label %bb, !dbg !1018
>
> bb: ; preds = %entry
> %tmp2 = load i16* %x, align 2, !dbg !1023 ; <i16> [#uses=1]
> %tmp3 = sext i16 %tmp2 to i32, !dbg !1023 ; <i32> [#uses=1]
> store i32 %tmp3, i32* %xx, align 4, !dbg !1023
> %tmp4 = load i16* %y, align 2, !dbg !1024 ; <i16> [#uses=1]
> %tmp5 = sext i16 %tmp4 to i32, !dbg !1024 ; <i32> [#uses=1]
> store i32 %tmp5, i32* %yy, align 4, !dbg !1024
> %tmp6 = load %struct.MT** @mt, align 8, !dbg !1025 ; <%struct.MT*>
> [#uses=1]
> call void @MTPoint_DIRECT(%struct.MT* %tmp6, i32* %xx, i32* %yy)
> nounwind
> %tmp8 = load i32* %xx, align 4, !dbg !1026 ; <i32> [#uses=1]
> %tmp9 = trunc i32 %tmp8 to i16, !dbg !1026 ; <i16> [#uses=1]
> store i16 %tmp9, i16* %x, align 2, !dbg !1026
> %tmp10 = load i32* %yy, align 4, !dbg !1027 ; <i32> [#uses=1]
> %tmp11 = trunc i32 %tmp10 to i16, !dbg !1027 ; <i16> [#uses=1]
> store i16 %tmp11, i16* %y, align 2, !dbg !1027
> ret void
>
> return: ; preds = %entry
> ret void
> }
>
> opt:
> /home/vadve/aggarwa4/llvm27/llvm-2.7/lib/VMCore/Instructions.cpp:307:
> void llvm::CallInst::init(llvm::Value*, llvm::Value* const*, unsigned
> int): Assertion `(NumParams == FTy->getNumParams() ||
(FTy->isVarArg()
> && NumParams > FTy->getNumParams())) && "Calling
a function with bad
> signature!"' failed.
>
>
> When I looked at the excption, it occurs when creating the CallInst.
>
> The type of the function being called at that point is still the old
> type, without the extra parameter, though the extra parameter seems to
> have been added when I dump DirectF.
>
> Can I get any pointers to what I am doing wrong, and what might be a
> potential solution.
>
> Thanks,
> Arushi
------------------------------
Message: 5
Date: Tue, 22 Feb 2011 14:20:56 -0600
From: greened at obbligato.org (David A. Greene)
Subject: Re: [LLVMdev] Structure Types and ABI sizes
To: Jochen Wilhelmy <j.wilhelmy at arcor.de>
Cc: "llvmdev at cs.uiuc.edu" <llvmdev at cs.uiuc.edu>
Message-ID: <nnghbbvstw7.fsf at royale.us.cray.com>
Content-Type: text/plain; charset=us-ascii
Jochen Wilhelmy <j.wilhelmy at arcor.de> writes:
> struct I {
> int a;
> char b;
> };
>
> struct J : I {
> char c;
> };
>
> Dave said that this translates to
>
> %I = type { i32, i8, i16 }
> %J = type { %I, i8, i16 }
It translates to that in OUR compiler. It's not the only answer.
> because the frontend has to communicate the ABI to llvm since llvm is
> language agnostic.
Correct.
> What I really wonder is why it isn't
>
> %I = type { i32, i8 }
> %J = type { %I, i16, i8 }
>
> because llvm at least knows alignment rules by
>
> target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16...
>
> Therefore llvm has no other choice than assigning %I a size of 8
> since an array may consist of %I elements and size of 5 would violate
> the aligment of the i32 member.
I can't quite parse this. %I doesn't get "assigned" a size by
anyone.
Do you meant the size of struct I is eight bytes? Yes, that's true.
> If the ABI requires that member c has an offset of 8 instead of 5 then
> of course a padding behind %I is necessary in %J.
Yes, the padding is required. I believe %J = type { %I, i16, i8 } would
work just as well as long as %I = type { i32, i8 } as in your example.
Our frontend is far from "perfect" in the sense of aesthetics. :)
-Dave
------------------------------
Message: 6
Date: Tue, 22 Feb 2011 12:23:27 -0800
From: Talin <viridia at gmail.com>
Subject: Re: [LLVMdev] still failed to build the llbrowse on
Debian5-32b-llvm2.8
To: Chuck Zhao <czhao at eecg.toronto.edu>
Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
Message-ID:
<AANLkTim8icrL_2ga0Bx1UJi8qqtG1KCZo_bcYnE8+x7R at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
OK try it now - I checked in a few more fixes.
On Tue, Feb 22, 2011 at 8:29 AM, Chuck Zhao <czhao at eecg.toronto.edu>
wrote:
> I still can't build LLBrowse on my Debian5-i386 machine today,
> The following is a full build console output.
> I am using LLVM-2.8 release build, with needed wxWidgets and CMake.
>
> Thank you
>
> Chuck
>
> sideshow.eecg>time cmake ../llbrowse
> -- The C compiler identification is GNU
> -- The CXX compiler identification is GNU
> -- Check for working C compiler: /steffan/a/a0/czhao/bin/bin32/gcc
> -- Check for working C compiler: /steffan/a/a0/czhao/bin/bin32/gcc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Found wxWidgets: TRUE
> -- Looking for assert.h
> -- Looking for assert.h - found
> -- Looking for auto_ptr.h
> -- Looking for auto_ptr.h - not found
> -- Looking for C++ include memory
> -- Looking for C++ include memory - found
> -- LLVM llvm-config found at:
> /steffan/a/a0/czhao/opt/opt32/llvm-2.8r/bin/llvm-config
> -- Configuring done
> -- Generating done
> -- Build files have been written to:
> /steffan/a/a0/czhao/ResearchTools/LLVM/LLBrowse/obj
> 1.976u 2.100s 0:14.37 28.3% 0+0k 48680+2392io 174pf+0w
> sideshow.eecg>time make
> [ 5%] Converting PNG image file resources/icons/folder.png
> [ 11%] Converting PNG image file resources/icons/collapse.png
> [ 16%] Converting PNG image file resources/icons/typeref.png
> [ 22%] Converting PNG image file resources/icons/expand.png
> [ 27%] Converting PNG image file resources/icons/type.png
> [ 33%] Converting PNG image file resources/icons/function.png
> [ 38%] Converting PNG image file resources/icons/module.png
> [ 44%] Converting PNG image file resources/icons/variable.png
> [ 50%] Converting PNG image file resources/icons/debug.png
> [ 55%] Converting PNG image file resources/icons/meta.png
> [ 61%] Converting PNG image file resources/icons/alias.png
> [ 66%] Converting PNG image file resources/icons/constant.png
> Scanning dependencies of target llbrowse
> [ 72%] Building CXX object CMakeFiles/llbrowse.dir/lib/BrowserFrame.cpp.o
> [ 77%] Building CXX object CMakeFiles/llbrowse.dir/lib/DetailsView.cpp.o
> [ 83%] Building CXX object CMakeFiles/llbrowse.dir/lib/BrowserApp.cpp.o
>
/steffan/a/a0/czhao/ResearchTools/LLVM/LLBrowse/llbrowse/lib/BrowserApp.cpp:
> In member function 'virtual bool BrowserApp::OnInit()':
>
/steffan/a/a0/czhao/ResearchTools/LLVM/LLBrowse/llbrowse/lib/BrowserApp.cpp:29:
> error: 'PrintStackTraceOnErrorSignal' is not a member of
'llvm::sys'
> make[2]: *** [CMakeFiles/llbrowse.dir/lib/BrowserApp.cpp.o] Error 1
> make[1]: *** [CMakeFiles/llbrowse.dir/all] Error 2
> make: *** [all] Error 2
> 7.228u 1.228s 0:12.34 68.3% 0+0k 13512+1784io 3pf+0w
>
> sideshow.eecg>
>
>
>
--
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110222/4bd0c5e3/attachment-0001.html
------------------------------
Message: 7
Date: Tue, 22 Feb 2011 23:27:01 +0300
From: Anton Korobeynikov <anton at korobeynikov.info>
Subject: [LLVMdev] repo.or.cz GIT mirrors
To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
Cc: clang-dev Developers <cfe-dev at cs.uiuc.edu>
Message-ID:
<AANLkTikKRAzvNaNSkezBRpG0r3HJ=2Y_5A0diUiv9BLd at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hello Everyone
As you might already know, git mirrors of llvm repository started from
repo.or.cz mirrors, where stuff was pushed almost by hands out of
git-svn local copy. Right now we have official and automatically
updated GIT mirrors on llvm.org and thus repo.or.cz mirrors look a bit
redundant. However, they might still be useful, but definitely not
within the current "push mode". It is possible to convert them to
plain GIT mirrors of llvm.org GIT mirrors with automatic pulling, but
this, in fact, will require us to delete repo.or.cz repos and recreate
them from scratch.
I hope this would affect only forks, from which only 1-2 seem to be
active (and hopefully they can be just recreated on top of new
projects).
Any objections for such procedure? Maybe someone will have better idea?
--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University
------------------------------
Message: 8
Date: Tue, 22 Feb 2011 14:34:55 -0600
From: greened at obbligato.org (David A. Greene)
Subject: Re: [LLVMdev] Questions about LLVM IR encoding
To: ?? <yueguoguo1024 at gmail.com>
Cc: llvmdev at cs.uiuc.edu
Message-ID: <nngd3mjst8w.fsf at royale.us.cray.com>
Content-Type: text/plain; charset=utf-8
?? <yueguoguo1024 at gmail.com> writes:
> Hi all, I am new to LLVM (even the field of compiler) and currently I am
engaged in the work of adapting LLVM IR to M5 simulator to observe
> the enhancement of the novel architecture we design.
> Simply speaking if you know?little about?M5, my aim is to know how LLVM IR
is interpreted and encoded, then try to implement it in the
> framework of M5.
> I have read the LLVM documents, yet I still have some questions as follows:
> ?
> 1. As IR is target-independent, how can we encode them into bit-code
executable files without specific?targets' information???
> 2. The "bitstream container format" as the document refers, is
XML-like, and I wonder how does LLVM translate it into executable format such
> as bit-code.
If I'm understanding you correctly, you want to treat LLVM IR as an ISA
and simulate that in M5, writing a new M5 target to execute LLVM IR in
bitcode format. Is that right?
I don't think that's a good option. While it can theoretically be done,
you're going to miss very important machine aspects such as:
- limited register set
- alignment issues
- calling sequence
- instruction/text size
There are others, but all of the above can impact performance in major
ways. Not modeling them is going to give you very inaccurate results.
If you can express your architectural enhancement in one of the existing
targets, I would do that. At the very worst you can create new
instructions (say, for x86) and insert them into the asm stream with raw
.byte directives in the .s file. I've done that many times in the past.
Another option is to create a new Target in LLVM and define the ISA you
want to evaluate. This is a lot more work as it requires a new Target
in LLVM and a new implementation for M5 but it gives you more
flexibility and makes future changes easier.
I would go with one of the existing Targets if possible and add any new
instructions you need. That's going to give you the most realistic
results.
-Dave
------------------------------
Message: 9
Date: Tue, 22 Feb 2011 12:43:27 -0800
From: Chris Lattner <clattner at apple.com>
Subject: Re: [LLVMdev] Clone a function and change signature
To: John Criswell <criswell at illinois.edu>
Cc: "llvmdev at cs.uiuc.edu" <llvmdev at cs.uiuc.edu>
Message-ID: <C1ECEFA4-FEB0-45BE-B9A8-E325548575F8 at apple.com>
Content-Type: text/plain; charset=us-ascii
On Feb 22, 2011, at 11:46 AM, John Criswell wrote:
> On 2/22/11 1:31 PM, Arushi Aggarwal wrote:
>> Hi,
>>
>> I want to clone a given function, and add an argument to it. I then
>> want to add a call to that new function. I have a callInstruction CI,
>> which I want to transform to call this new function, and to take a new
>> argument.
>
> If I understand correctly, you're cloning the function first and then
> adding a new argument to the clone. Do I understand correctly?
>
> If so, I don't believe you can do that. IIRC, you have to first create
> a new, empty function with the additional argument and then use
> CloneFunctionInto() to clone the body of the original function into the
> new function. I believe that's what poolalloc does and what I did the
> last time I had to add function arguments to a function.
Right, you can also take a look at the dead argument elimination or argument
promotion passes for examples.
-Chris
------------------------------
Message: 10
Date: Tue, 22 Feb 2011 12:44:18 -0800
From: Chris Lattner <clattner at apple.com>
Subject: Re: [LLVMdev] Question about Value Range Propagation
To: Reid Kleckner <reid.kleckner at gmail.com>
Cc: llvmdev at cs.uiuc.edu
Message-ID: <1D82F914-A36A-4447-B36C-70E46F35B751 at apple.com>
Content-Type: text/plain; charset=us-ascii
On Feb 22, 2011, at 7:25 AM, Reid Kleckner wrote:
> On Tue, Feb 22, 2011 at 6:19 AM, Duncan Sands <baldrick at free.fr>
wrote:
>> the big problem with Patterson's VRP is that it is expensive in
terms of
>> compile time. LLVM used to have some passes (ABCD, predsimplify) that
did
>> this kind of thing, but they were removed essentially because their
compile
>> time was too great for the goodness they brought.
>
> Any reason not to just leave them on at O3? Based on the discussion
> around your simple condition propagation pass, it seemed predsimplify
> did delete dead code, but it didn't really improve generated code
> performance. O3 seems the appropriate place to put expensive
> optimizations with diminishing returns.
Hi Reid,
-O3 compile time matters. We don't turn things on in -O3 or -O4 that just
burn compiler cycles but don't add value.
-Chris
------------------------------
Message: 11
Date: Tue, 22 Feb 2011 12:44:41 -0800
From: Chris Lattner <clattner at apple.com>
Subject: Re: [LLVMdev] unary floating point operations using clang
To: Alexandru Dura <alexdura at gmail.com>
Cc: llvmdev at cs.uiuc.edu
Message-ID: <C8491C5B-9ED2-4620-8B79-062CC2C4DAAC at apple.com>
Content-Type: text/plain; charset=us-ascii
On Feb 22, 2011, at 12:40 AM, Alexandru Dura wrote:
> Hello,
>
> Is there a way of generating unary floating point operations (like
ISD::FABS, ISD::FSIN, ...) from C code using clang? I am building a backend for
a machine that has hw support for these ops and I need a way to test them.
Sure, just call sin() and cos().
-Chris
------------------------------
Message: 12
Date: Tue, 22 Feb 2011 14:57:34 -0600
From: John Criswell <criswell at illinois.edu>
Subject: Re: [LLVMdev] Question about Value Range Propagation
To: Duncan Sands <baldrick at free.fr>
Cc: "llvmdev at cs.uiuc.edu" <llvmdev at cs.uiuc.edu>
Message-ID: <4D64233E.20006 at illinois.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
On 2/22/11 5:19 AM, Duncan Sands wrote:> Hi Andrey,
>
>> On 21.02.2011 20:27, Douglas do Couto Teixeira wrote:
>>> My work is not part of the LLVM mainline yet. But I would be happy
to
>>> contribute with the code of my range analysis implementation if it
can help
>>> you in something else.
>> We were thinking of adding VRP to LLVM too, though we were mostly
>> interested in Patterson's approach (i.e. not connected with SSI
form). It
>> would be great if you can share the code nevertheless.
> the big problem with Patterson's VRP is that it is expensive in terms
of
> compile time. LLVM used to have some passes (ABCD, predsimplify) that did
> this kind of thing, but they were removed essentially because their compile
> time was too great for the goodness they brought.
I was under the impression that ABCD was removed because no one was
maintaining and improving it. Is my impression incorrect?
The SAFECode compiler adds additional run-time checks for array bounds
checking. If the ABCD code was working but just wasn't useful for
regular C code, I'd like to know. It may still have value for projects
like SAFECode.
-- John T.
> Ciao, Duncan.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
------------------------------
Message: 13
Date: Tue, 22 Feb 2011 16:36:03 -0500
From: Chuck Zhao <czhao at eecg.toronto.edu>
Subject: Re: [LLVMdev] still failed to build the llbrowse on
Debian5-32b-llvm2.8
To: Talin <viridia at gmail.com>
Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
Message-ID: <4D642C43.7030806 at eecg.toronto.edu>
Content-Type: text/plain; charset="iso-8859-1"
Nice,
It builds and runs fine now.
Thank you, Talin
Chuck
On 2/22/2011 3:23 PM, Talin wrote:> OK try it now - I checked in a few more fixes.
>
> On Tue, Feb 22, 2011 at 8:29 AM, Chuck Zhao <czhao at eecg.toronto.edu
> <mailto:czhao at eecg.toronto.edu>> wrote:
>
> I still can't build LLBrowse on my Debian5-i386 machine today,
> The following is a full build console output.
> I am using LLVM-2.8 release build, with needed wxWidgets and CMake.
>
> Thank you
>
> Chuck
>
> sideshow.eecg>time cmake ../llbrowse
> -- The C compiler identification is GNU
> -- The CXX compiler identification is GNU
> -- Check for working C compiler: /steffan/a/a0/czhao/bin/bin32/gcc
> -- Check for working C compiler: /steffan/a/a0/czhao/bin/bin32/gcc
> -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Found wxWidgets: TRUE
> -- Looking for assert.h
> -- Looking for assert.h - found
> -- Looking for auto_ptr.h
> -- Looking for auto_ptr.h - not found
> -- Looking for C++ include memory
> -- Looking for C++ include memory - found
> -- LLVM llvm-config found at:
> /steffan/a/a0/czhao/opt/opt32/llvm-2.8r/bin/llvm-config
> -- Configuring done
> -- Generating done
> -- Build files have been written to:
> /steffan/a/a0/czhao/ResearchTools/LLVM/LLBrowse/obj
> 1.976u 2.100s 0:14.37 28.3% 0+0k 48680+2392io 174pf+0w
> sideshow.eecg>time make
> [ 5%] Converting PNG image file resources/icons/folder.png
> [ 11%] Converting PNG image file resources/icons/collapse.png
> [ 16%] Converting PNG image file resources/icons/typeref.png
> [ 22%] Converting PNG image file resources/icons/expand.png
> [ 27%] Converting PNG image file resources/icons/type.png
> [ 33%] Converting PNG image file resources/icons/function.png
> [ 38%] Converting PNG image file resources/icons/module.png
> [ 44%] Converting PNG image file resources/icons/variable.png
> [ 50%] Converting PNG image file resources/icons/debug.png
> [ 55%] Converting PNG image file resources/icons/meta.png
> [ 61%] Converting PNG image file resources/icons/alias.png
> [ 66%] Converting PNG image file resources/icons/constant.png
> Scanning dependencies of target llbrowse
> [ 72%] Building CXX object
> CMakeFiles/llbrowse.dir/lib/BrowserFrame.cpp.o
> [ 77%] Building CXX object
> CMakeFiles/llbrowse.dir/lib/DetailsView.cpp.o
> [ 83%] Building CXX object
> CMakeFiles/llbrowse.dir/lib/BrowserApp.cpp.o
>
/steffan/a/a0/czhao/ResearchTools/LLVM/LLBrowse/llbrowse/lib/BrowserApp.cpp:
> In member function 'virtual bool BrowserApp::OnInit()':
>
/steffan/a/a0/czhao/ResearchTools/LLVM/LLBrowse/llbrowse/lib/BrowserApp.cpp:29:
> error: 'PrintStackTraceOnErrorSignal' is not a member of
'llvm::sys'
> make[2]: *** [CMakeFiles/llbrowse.dir/lib/BrowserApp.cpp.o] Error 1
> make[1]: *** [CMakeFiles/llbrowse.dir/all] Error 2
> make: *** [all] Error 2
> 7.228u 1.228s 0:12.34 68.3% 0+0k 13512+1784io 3pf+0w
>
> sideshow.eecg>
>
>
>
>
>
> --
> -- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110222/b4bb8299/attachment-0001.html
------------------------------
Message: 14
Date: Tue, 22 Feb 2011 16:47:40 -0500
From: Dineth <dineth2007 at gmail.com>
Subject: [LLVMdev] duplicate .debug_line sections
To: llvmdev <llvmdev at cs.uiuc.edu>
Message-ID:
<AANLkTinmE-vqUhwpX86+yJVHk0Jd_6g=C6js65MSJ=cJ at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
I'm using LLVM 2.8 with GNU Binutils for Ubuntu
2.20.51-system.20100908. When I try to assemble a .s file generated
with llc with g++ I get the error:
Fatal error: duplicate .debug_line sections.
I'm using llvm-gcc/g++ as front end.
I also tried generating the .o file directly using -filetype=obj but
that too fails with
BFD: BFD (GNU Binutils for Ubuntu) 2.20.51-system.20100908 assertion
fail ../../bfd/elf.c:1805
when trying to convert the .o file to an archive with ar.
I would appreciate any help very much. Thanks.
-- dineth
------------------------------
Message: 15
Date: Tue, 22 Feb 2011 13:54:44 -0800
From: Devang Patel <dpatel at apple.com>
Subject: Re: [LLVMdev] duplicate .debug_line sections
To: Dineth <dineth2007 at gmail.com>
Cc: llvmdev <llvmdev at cs.uiuc.edu>
Message-ID: <41D33723-1B56-4AB0-A239-301A21902E5E at apple.com>
Content-Type: text/plain; charset=us-ascii
On Feb 22, 2011, at 1:47 PM, Dineth wrote:
> I'm using LLVM 2.8 with GNU Binutils for Ubuntu
> 2.20.51-system.20100908. When I try to assemble a .s file generated
> with llc with g++ I get the error:
>
> Fatal error: duplicate .debug_line sections.
This is probably http://llvm.org/bugs/show_bug.cgi?id=6218
-
Devang>
> I'm using llvm-gcc/g++ as front end.
>
> I also tried generating the .o file directly using -filetype=obj but
> that too fails with
>
> BFD: BFD (GNU Binutils for Ubuntu) 2.20.51-system.20100908 assertion
> fail ../../bfd/elf.c:1805
>
> when trying to convert the .o file to an archive with ar.
>
> I would appreciate any help very much. Thanks.
>
------------------------------
Message: 16
Date: Tue, 22 Feb 2011 17:01:53 -0500
From: Chuck Zhao <czhao at eecg.toronto.edu>
Subject: [LLVMdev] obtain the address and size of LLVM generated
temporaries
To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
Message-ID: <4D643251.1080809 at eecg.toronto.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I wonder what is the right approach to obtain the address and size of
LLVM (compiler) generated temporaries?
E.g.
%0 = %x + %y
store i32 i0, i32 %z, align 4
How can I get the address of %0 (which could be either a stack or heap
variable)?
Thank you
Chuck
------------------------------
Message: 17
Date: Tue, 22 Feb 2011 14:29:13 -0800
From: Yuri <yuri at rawbw.com>
Subject: Re: [LLVMdev] obtain the address and size of LLVM generated
temporaries
To: Chuck Zhao <czhao at eecg.toronto.edu>
Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
Message-ID: <4D6438B9.9050405 at rawbw.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 02/22/2011 14:01, Chuck Zhao wrote:> I wonder what is the right approach to obtain the address and size of
> LLVM (compiler) generated temporaries?
>
> E.g.
>
> %0 = %x + %y
> store i32 i0, i32 %z, align 4
>
> How can I get the address of %0 (which could be either a stack or heap
> variable)?
>
This is not possible since such value can also be in register.
Yuri
------------------------------
Message: 18
Date: Tue, 22 Feb 2011 23:39:07 +0100
From: Jochen Wilhelmy <j.wilhelmy at arcor.de>
Subject: Re: [LLVMdev] Structure Types and ABI sizes
To: "David A. Greene" <greened at obbligato.org>
Cc: "llvmdev at cs.uiuc.edu" <llvmdev at cs.uiuc.edu>
Message-ID: <4D643B0B.1090809 at arcor.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>> What I really wonder is why it isn't
>>
>> %I = type { i32, i8 }
>> %J = type { %I, i16, i8 }
>>
>> because llvm at least knows alignment rules by
>>
>> target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16...
>>
>> Therefore llvm has no other choice than assigning %I a size of 8
>> since an array may consist of %I elements and size of 5 would violate
>> the aligment of the i32 member.
> I can't quite parse this. %I doesn't get "assigned" a
size by anyone.
> Do you meant the size of struct I is eight bytes? Yes, that's true.
Yes I mean that
%I = type { i32, i8 }
is 8 bytes given the alignment rules (i.e. llvm "assigns" a size of
8 bytes to this struct after parsing it)
> Yes, the padding is required. I believe %J = type { %I, i16, i8 } would
> work just as well as long as %I = type { i32, i8 } as in your example.
Yes but given the ABI requires the last member to be at offset 5, which
may happen
(i.e. no tail padding if I is derived from), then your solution
%I = type { i32, i8, i16 }
is problematic or do you switch struct generation dependent on the ABI?
The question arises to me since I would use an "always working"
solution
(with no case distinction) but of course I'm not deep enough in the matter.
-Jochen
------------------------------
Message: 19
Date: Tue, 22 Feb 2011 15:37:19 -0800
From: drizzle drizzle <drizzle76 at gmail.com>
Subject: [LLVMdev] virtual register does not exist
To: LLVMdev at cs.uiuc.edu
Message-ID:
<AANLkTinpkH8wfYyTrFRoGd6uiS-m5wfXXb6KJZq45K40 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi
is there a way to know later that an earlier pass inside the codegen
might have eliminated a virtual register.
I carry information abt virtual registers which i would like to update
if any virtual register does not exist since.
thanks
dz
------------------------------
Message: 20
Date: Tue, 22 Feb 2011 15:46:30 -0800
From: John Myers <atomicdog.jwm at gmail.com>
Subject: Re: [LLVMdev] Looking for more LLBrowse testers / users
To: Talin <viridia at gmail.com>, LLVM Developers Mailing List
<llvmdev at cs.uiuc.edu>
Message-ID:
<AANLkTikB3=ty6x0CY8qFygjbZTgMBtJqdC1DNSri8i8H at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Tue, Feb 22, 2011 at 3:30 PM, Talin <viridia at gmail.com> wrote:
> This should be fixed now.
> --
> -- Talin
>
Thanks, It compiles and runs now.
--John
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110222/167f6951/attachment-0001.html
------------------------------
Message: 21
Date: Tue, 22 Feb 2011 16:24:47 -0800
From: Jakob Stoklund Olesen <stoklund at 2pi.dk>
Subject: Re: [LLVMdev] virtual register does not exist
To: drizzle drizzle <drizzle76 at gmail.com>
Cc: LLVMdev at cs.uiuc.edu
Message-ID: <F9916400-4757-4791-9A0D-BD9448FD7818 at 2pi.dk>
Content-Type: text/plain; charset=us-ascii
On Feb 22, 2011, at 3:37 PM, drizzle drizzle wrote:
> Hi
> is there a way to know later that an earlier pass inside the codegen
> might have eliminated a virtual register.
> I carry information abt virtual registers which i would like to update
> if any virtual register does not exist since.
You can check if any instructions are using it with
MRI->reg_nodbg_empty(Reg).
/jakob
------------------------------
Message: 22
Date: Tue, 22 Feb 2011 19:46:24 -0500
From: F?lix Cloutier <felixcca at yahoo.ca>
Subject: Re: [LLVMdev] Can I use Clang to parse snippets of C++ code?
To: Chris Lattner <clattner at apple.com>
Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
Message-ID: <5E4C34C9-B5D2-4F6C-819F-25E79E217479 at yahoo.ca>
Content-Type: text/plain; charset="iso-8859-1"
I believe that what I'm trying to do with Clang is fairly simple; the final
goal, however, might be a little harder.
Knowing myself, there are chances I'll never go through with this project
(like Mikael who posted earlier, I'm nothing but an enthusiastic student
with lots of time on my hands), but it feels cool enough to me to announce my
idea. Besides, I'll probably need help from more knowledgeable people
anyways.
The way LLVM works makes it pretty easy and straightforward to generate code
from nested structures (like ASTs), which is totally commendable since LLVM is a
compiler back-end. However, in the past months I've set myself to make an
emulator back-end with LLVM that would translate machine code to LLBC then
compile it to native code with the JIT, and my experience haven't been so
great, especially because of the following:
it's stupid-hard to debug just-in-time generated code with the version of
gdb that ships with Xcode (it repeatedly crashed on me);
the sheer number of cases to treat is, in itself, rebuking enough: a NES 6502 is
'fine' with just less than 60 distinct operations, but the full-fledged
PowerPC you get with a GameCube has roughly 6 times more;
when faced with subtle bugs, it's much easier to deal with C++ code
representing what you want to do (like interpreter code) than IRBuilder::Create*
calls.
I figured that while I can't do much about the first, if I could get LLVM to
generate code that would generate code, the two others would be much less
cumbersome.
So my plan is to write a tool that accepts a specification of how instructions
should be interpreted, with handlers written in C++, and turn that into an
usable recompiler (that would also use LLVM libraries). The grammar would be a
shell for C++ code, and I'd use Clang to turn the actual code into LLBC;
then, I would pass through the code (? la llvm2cpp), and create calls to an
IRBuilder to generate equivalent code. Once this generated class compiled
(through regular means), clients would call the appropriate methods on the
object to generate code, and will finally be able to get a Function to use with
the JIT.
I've joined an example grammar and an example expected output (made on the
train, it's not actually working, but it gives a good idea).
Branch management (except for the branching itself) would have to be completely
managed by the client, but this is a minor hurt compared to what it is right
now.
As a side-effect of using C++ to make instruction handlers, such a solution
could almost be a drop-in replacement for existing interpreters.
So this is what I'd like to be able to compile with Clang: snippets of C++,
with a few symbols declared beforehand.
F?lix
Le 2011-02-21 ? 23:35:55, Chris Lattner a ?crit :
>
> On Feb 21, 2011, at 6:31 PM, F?lix Cloutier wrote:
>
>> Hello guys,
>>
>> I'd like to use Clang to parse snippets of (and emit bytecode for)
C++ code that come from larger files that don't contain only C++, but
looking at the clang interpreter example, either I didn't get it, or it
looks like the driver expects only files, and not strings or char buffers.
>>
>> Is there a simple way to achieve this? Do I have to split my input into
small files and pass them to clang, or is there a better way?
>
> It depends on exactly what you're trying to achieve. LLDB uses clang
to parse individual expressions, and does this by hooking into various name
lookup routines to dynamically/lazily populate symbol tables from debug info.
>
> This is all possible, but it's a nontrivial amount of work.
>
> -Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110222/bebb8b03/attachment.html
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: example.txt
Url:
http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110222/bebb8b03/attachment.txt
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20110222/bebb8b03/attachment-0001.html
------------------------------
_______________________________________________
LLVMdev mailing list
LLVMdev at cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
End of LLVMdev Digest, Vol 80, Issue 37
***************************************
Possibly Parallel Threads
- [LLVMdev] still failed to build the llbrowse on Debian5-32b-llvm2.8
- [LLVMdev] still failed to build the llbrowse on Debian5-32b-llvm2.8
- [LLVMdev] Clone a function and change signature
- [LLVMdev] Clone a function and change signature
- [LLVMdev] Looking for more LLBrowse testers / users
Wisdom of the Ancients
