Displaying 20 results from an estimated 2000 matches similar to: "[LLVMdev] Name of Function's original module during link-time optimization"
2006 Sep 24
0
[LLVMdev] Name of Function's original module during link-time optimization
Hi Bram,
On Sun, 2006-09-24 at 22:58 +0200, Bram Adams wrote:
> Hi,
>
> During link-time optimization using llvm-ld, I occasionally need to
> find the name/ID of the original module/bytecode file a Function
> belonged to. In order to do this I added a nameOfPreviousModule-
> attribute to Function and some getters/setters (see attached patch).
> However, I can't
2006 Sep 25
2
[LLVMdev] Name of Function's original module during link-time optimization
Hi,
Reid Spencer wrote:
> Call getBytecodeModuleProvider (see Reader.h).
The problem is that one needs to provide the filename of the original
module as the argument of getBytecodeModuleProvider, whereas this is
unknown (it's exactly what we're trying to find out).
But, by looking where this method is called in the original bytecode
loading process, I figured out a way to set the
2006 Sep 25
0
[LLVMdev] Name of Function's original module during link-time optimization
On Mon, 25 Sep 2006, Bram Adams wrote:
> Reid Spencer wrote:
>> Call getBytecodeModuleProvider (see Reader.h).
> The problem is that one needs to provide the filename of the original module
> as the argument of getBytecodeModuleProvider, whereas this is unknown (it's
> exactly what we're trying to find out).
>
> But, by looking where this method is called in the
2006 Sep 25
2
[LLVMdev] Name of Function's original module during link-time optimization
Hi,
Op 25-sep-06, om 23:26 heeft Chris Lattner het volgende geschreven:
> On Mon, 25 Sep 2006, Bram Adams wrote:
>> Haven't tried them extensively yet, so I'm
>> wondering whether the remark in your mail of 09/04/2006 to Nikhil
>> Patil about
>> "-g currently disables many optimizations" still holds.
>
> Yes, that is true. What are you trying
2006 Sep 25
2
[LLVMdev] Name of Function's original module during link-time optimization
Hi,
Op 25-sep-06, om 20:07 heeft Chris Lattner het volgende geschreven:
> What are you trying to accomplish? Why not use location records from
> debug info?
You mean the debugging intrinsics? Just discovered them :-), and I
guess that's exactly what I need. Haven't tried them extensively yet,
so I'm wondering whether the remark in your mail of 09/04/2006 to
Nikhil Patil
2006 Sep 25
0
[LLVMdev] Name of Function's original module during link-time optimization
On Mon, 25 Sep 2006, Bram Adams wrote:
> Op 25-sep-06, om 20:07 heeft Chris Lattner het volgende geschreven:
>> What are you trying to accomplish? Why not use location records from
>> debug info?
>
> You mean the debugging intrinsics? Just discovered them :-), and I guess
> that's exactly what I need. Haven't tried them extensively yet, so I'm
>
2006 Sep 25
0
[LLVMdev] Name of Function's original module during link-time optimization
On Mon, 25 Sep 2006, Bram Adams wrote:
>> On Mon, 25 Sep 2006, Bram Adams wrote:
>>> Haven't tried them extensively yet, so I'm
>>> wondering whether the remark in your mail of 09/04/2006 to Nikhil
>>> Patil about
>>> "-g currently disables many optimizations" still holds.
>>
>> Yes, that is true. What are you trying to do?
2006 Sep 26
2
[LLVMdev] Name of Function's original module during link-time optimization
Hi,
Chris Lattner wrote:
> I'd suggest writing a little pass that strips out debug intrinsics.
>
OK, I did this and it works (the strange seg fault also disappears after
all declared debug variables are gone)! In a first phase, all intrinsic
instructions are discarded after extracting their data into annotations
attached to the relevant Function. Then, a second phase wipes out the
2006 Aug 20
3
[LLVMdev] Weird behavior of llvm-ld
Hi,
Op 20-aug-06, om 21:18 heeft Reid Spencer het volgende geschreven:
> I looked over your patch and it looks good. I applied a patch based on
> yours. The llvm-ld tool now uses the PluginLoader just like the opt
> tool. It will also run some cleanup passes after the loaded plugins
> run
> to ensure cruft is removed.
OK, thanks. Your patch seems to work, although I also get
2007 May 29
4
[LLVMdev] Code generation issues
Hi,
Today I managed to link ioquake3, but generating a binary does not
work yet.
1) On OSX, I get:
Error: Code generator does not support intrinsic function
'llvm.ppc.altivec.lvsl'!
when I do: llc file.bc -march=c -o file.c
2) On Linux X86, llc does not give any problem, but I get this while
compiling the generated .c file:
error: unknown register name 'S' in
2007 Jul 05
2
[LLVMdev] PATCH (rest of code changes) "bytecode" --> "bitcode"
Here is the bulk of the sanitizing.
My residual doubts center around the question
whether we still do/want to support (un)compressed *byte*code
in 2.0/2.1.
I need a definitive word on this to proceed.
My understanding is that bytecode is already gone, but there are
still some functions/enums that really deal with *byte*code
(instead of *bit*code).
I did not touch those areas, so the attached
2007 May 18
0
[LLVMdev] Antw.: 2.0 Pre-release tarballs online
> On Slackware 10.2 (GCC 3.3.6), I got an error during a debug build with the
> header files using uintptr_t (not recognised as a type). Putting "#include
> <stdint.h>" in include/llvm/BasicBlock.h (llvm) and in
> "include/llvm/ValueSymbolTable.h" (frontend) resolved this.
Ok. This is now fixed on the release branch. Thanks!
> Also, I got linking
2007 May 17
8
[LLVMdev] Antw.: 2.0 Pre-release tarballs online
Hi,
Op 15-mei-07, om 10:23 heeft Tanya M. Lattner het volgende geschreven:
1) Download llvm-gcc4 binary and llvm. Compile and run make check.
I did a debug build on OSX 10.4.9 and everything went fine.
Results of "make check" (see ppc.log):
=== Summary ===
# of expected passes 1630
# of unexpected failures 21
# of expected failures 2
2006 Nov 15
4
[LLVMdev] 1.9 Prerelease Available for Testing
Hi,
There is a typo in $LLVM_SRC/Makefile.rules on line 750 where it says :
SharedLibKindMessage := "Lodable Module"
instead of
SharedLibKindMessage := "Loadable Module"
Op 15-nov-06, om 15:54 heeft Bram Adams het volgende geschreven:
> Didn't check
> LLVM's test suite.
Doing the simple LLVM-tests (on Slackware 10.2) gets:
=== Summary ===
2006 Nov 15
3
[LLVMdev] 1.9 Prerelease Available for Testing
> When building LLVM 1.9 on OSX 10.4.8, I get (after a while, see attachment):
>
> make[1]: *** No rule to make target `/path/to/llvm-build/Debug/bin/tblgen',
> needed by `/path/to/llvm-build/lib/VMCore/Debug/Intrinsics.gen.tmp'. Stop.
> make: *** [install] Error 1
>
> when doing:
>
> $LLVM_SRC/configure --prefix=$LLVM_INSTALL --with-llvmgccdir=$LLVM_FRONT
2006 Aug 20
0
[LLVMdev] Weird behavior of llvm-ld
Do you have a verify option in your loaded module?
Reid.
On Sun, 2006-08-20 at 22:04 +0200, Bram Adams wrote:
> Hi,
>
> Op 20-aug-06, om 21:18 heeft Reid Spencer het volgende geschreven:
>
> > I looked over your patch and it looks good. I applied a patch based on
> > yours. The llvm-ld tool now uses the PluginLoader just like the opt
> > tool. It will also run
2007 May 18
2
[LLVMdev] Antw.: 2.0 Pre-release tarballs online
Hi,
Op 18-mei-07, om 10:10 heeft Tanya M. Lattner het volgende geschreven:
>> On Slackware 10.2 (GCC 3.3.6), I got an error during a debug build
>> with the header files using uintptr_t (not recognised as a type).
>> Putting "#include <stdint.h>" in include/llvm/BasicBlock.h (llvm)
>> and in "include/llvm/ValueSymbolTable.h" (frontend)
2006 Aug 20
2
[LLVMdev] Weird behavior of llvm-ld
Hi,
Op 20-aug-06, om 22:26 heeft Reid Spencer het volgende geschreven:
> Do you have a verify option in your loaded module?
What exactly do you mean by "verify option"? Anyway, I did a grep on
"verify" in my code, but found nothing.
Kind regards,
Bram Adams
GH-SEL, INTEC, Ghent University (Belgium)
2006 Nov 15
0
[LLVMdev] 1.9 Prerelease Available for Testing
Hi,
Op 15-nov-06, om 03:26 heeft Tanya M. Lattner het volgende geschreven:
> I'm able to reproduce this if I skip doing a "make" and directly do a
> "make install" after configuring. I believe we require people to do
> a full
> build before attempting to install. So I don't think its really a bug.
> Could you try doing a make first and then install?
2008 Jul 09
2
[LLVMdev] Add RTLD_GLOBAL to dlopen
Hi,
Today, I've made the transition from LLVM 2.1 to 2.3. I invoke opt
with two dynamic libraries to "-load", the first of which contains
transformation passes and support code whereas the second one provides
extra passes which make use of the first library's support code. In
other words, the symbols loaded in for the first library should be
available when the second