search for: reopt

Hello, In preparation for the LLVM public release, I've moved the reoptimizer out of the main cvs module "llvm" and into the cvs module "reopt". You can go ahead and delete the lib/Reoptimizer directory from your tree, about which cvs will undoubtedly be complaining to you. If you want to build the reoptimizer, cd into your SPARC tree's "p...

...d change speeds up links slightly because libraries are properly searched for symbols. I have also removed redundant variable definitions and sub-shell invocations (replaced with GNU Make features). I have tested these changes quite extensively including the Stacker, sample, llvm-test, Java and reopt projects. If you have another project, you MIGHT be impacted because of a few variable name changes. All changes will (soon) be documented in a new "LLVM Makefiles" document that I'll write, but quickly, here's what changed from a USER's perspective: * ExtraSource variable...

...ks slightly because libraries are > properly searched for symbols. I have also removed redundant variable > definitions and sub-shell invocations (replaced with GNU Make features). > > I have tested these changes quite extensively including the Stacker, sample, > llvm-test, Java and reopt projects. If you have another project, you MIGHT be > impacted because of a few variable name changes. > > All changes will (soon) be documented in a new "LLVM Makefiles" document that > I'll write, but quickly, here's what changed from a USER's perspective: >...

...the same issue with 6.01, and possibly earlier versions. 2. 6.01 works slowly, but successfully. 6.02 works slowly, and fail. With both 6.01 and 6.02, hello.c32 is reporting the malloc issue. It takes a long time to run, but it does exit. In contrast to 6.01, the xp command for 6.02 reopts an ERR: Couldn't read the first disk sector I pressed ctrl+alt+del immediately afterwards. Was I wrong not to wait a few minutes before doing that? 3. The following is mostly for the record. I seldom reboot the machine. I think I have no malware. I do get MS updates for...

In preparation for Release 1.4, I've consolidated the bytecode compression to only use bzip2. zlib is not supported any more. We chose bzip2 because it offers about 10% better compression on bytecode files. Its unlikely, but this change *could* affect you if you ever built the CFE or your own LLVM project on a machine that had zlib but didn't have bzip2. If you have bzip2 on your

Currently the blacklist is maintained by hand in kprobes.c which is separated from the function definition and is hard to catch up the kernel update. To solve this issue, I've tried to implement new NOKPROBE_SYMBOL() macro for making kprobe blacklist at build time. Since the NOKPROBE_SYMBOL() macros can be placed right after the function is defined, it is easy to maintain. This series

Currently the blacklist is maintained by hand in kprobes.c which is separated from the function definition and is hard to catch up the kernel update. To solve this issue, I've tried to implement new NOKPROBE_SYMBOL() macro for making kprobe blacklist at build time. Since the NOKPROBE_SYMBOL() macros can be placed right after the function is defined, it is easy to maintain. This series

Hi, Here is the version 3 of NOKPORBE_SYMBOL series. Currently the blacklist is maintained by hand in kprobes.c which is separated from the function definition and is hard to catch up the kernel update. To solve this issue, I've introduced NOKPROBE_SYMBOL() macro for making kprobe blacklist at build time. Since the NOKPROBE_SYMBOL() macros can be placed right after the function is defined

Hi, Here is the version 3 of NOKPORBE_SYMBOL series. Currently the blacklist is maintained by hand in kprobes.c which is separated from the function definition and is hard to catch up the kernel update. To solve this issue, I've introduced NOKPROBE_SYMBOL() macro for making kprobe blacklist at build time. Since the NOKPROBE_SYMBOL() macros can be placed right after the function is defined