similar to: [LLVMdev] me being stupid: me vs the llvm codebase...

On Oct 23, 2007, at 05:52, BGB wrote: > I am assuming then that some external assembler is used (such as > 'gas')?... In the static compilers, yes. The JIT directly serializes instructions into memory without the aid of an external assembler. There are also experimental built-in assemblers; LLVM calls them object writers[1]. > it looks like much of the interconnection

----- Original Message ----- From: "Gordon Henriksen" <gordonhenriksen at mac.com> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Wednesday, October 24, 2007 1:45 AM Subject: Re: [LLVMdev] me being stupid: me vs the llvm codebase... On Oct 23, 2007, at 05:52, BGB wrote: > I am assuming then that some external assembler is used (such as >

On Oct 23, 2007, at 18:19, BGB wrote: > On Oct 23, 2007, at 11:45, Gordon Henriksen wrote: > >> Generally speaking, LLVM neither helps nor hinders here. Maybe >> someone will follow up with whether the JIT uses stub functions >> which would enable dynamic relinking If not, it would be a >> straightforward, if platform-specific, feature to add. > > I

oh, ok. actually, I had partly considered this approach at one point, but opted with the form I did instead (in large part because it does not involve such a tweak, or dependency on the previous location). of course, as noted, due to the possibility of function pointers, this is a little risky. I had not considered this issue previously, but it is definitely worth consideration... I guess the

On Wed, 24 Oct 2007, BGB wrote: > even more interestingly: if the same compiler were also used for static > compilation, it could be used as a special feature to make such dynamic > movability available even for statically compiled and linked code (as > is, in my case, parts of the app which are statically compiled and > linked, can't currently be relinked...). LLVM handles

Hi all, My name is Fahad Nayyar. I am an undergraduate student from India. I am interested to participate in GSOC under the project “Improve inter-procedural analyses and optimizations”. I have been using LLVM for the past 8 months. I have written various intra-procedural analysis in LLVM as FunctionPass for my course projects and research projects. But I’ve not contributed to the LLVM

I am using, http://www.rd.dnc.ac.jp/~otsu/lecture/RwithMKL.html to compile R 2.10 . Everything compiles fine but I was wondering if there are any more optimizations I can do with the flags.

Hi Fahad, > > Improve dynamic memory related capabilities of Attributor. For example > Improve HeapToStackConversions. Maybe such deductions can help safety > (dis)provers. For example, can we improve the use-after-free bug detection > using some attributes? > Stefan should know more about H2S. Regarding the use-after-free, I don't > think there's currently any plans

There seems to be a lot of interest recently in LTO. How do you see the situation of splitting the IR passes between per-TU processing and multi-TU ("link time") processing? -- Sean Silva -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130717/f5310a6e/attachment.html>

Hi Farad, > I tried to do this for the NoUnwind attribute Hmm, I don't have experience with this attribute but it seems like a good starting point since it doesn't do much. First of all, be sure that you run with: opt -passes=attributor -attributor-disable=false This uses the new pass manager which is another discussion. Now, to the point: If you open nounwind.ll, it has a bunch of

----- Original Message ----- From: "Chris Lattner" <sabre at nondot.org> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Wednesday, October 24, 2007 11:30 AM Subject: Re: [LLVMdev] me being stupid: me vs the llvm codebase... > On Wed, 24 Oct 2007, BGB wrote: >> even more interestingly: if the same compiler were also used for static

Andy and I briefly discussed this the other day, we have not yet got chance to list a detailed pass order for the pre- and post- IPO scalar optimizations. This is wish-list in our mind: pre-IPO: based on the ordering he propose, get rid of the inlining (or just inline tiny func), get rid of all loop xforms... post-IPO: get rid of inlining, or maybe we still need it, only

Hi All, I have a two-part de-virtualization enhancement that I'm considering working on and am looking for any feedback on how feasible it is. The two parts are: 1. llvm: Extending inter-procedural SCCP (or some other IPO module pass) to propagate llvm.assume's across function calls. The basic idea would be to collect the set of assumptions for each argument at each call

Hi, There: This is the proposal for parallelizing post-ipo stage. See the following for details. I also attach a toy-grade rudimentary implementation. This implementation can be used to illustrate some concepts here. This patch is not going to be committed. Unfortunately, this weekend I will be too busy to read emails. Please do not construe delayed response as being rude :-).

----- Original Message ----- > From: "Chandler Carruth" <chandlerc at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Philip Reames" > <listmail at philipreames.com>, "Duncan P. N. Exon Smith" > <dexonsmith at apple.com>, "Xinliang David Li"

I am a grad CS student at Stanford and wanted to engage with EJ Park, Giorgis Georgakoudis, Johannes Doerfert to further develop the Machine Learning and Compiler Optimization concept. My background is in machine learning, cluster computing, distributed systems etc. I am a good C/C++ developer and have a strong background in algorithms and data structure. I am also taking an advanced compiler

>> LLVM handles function pointers currently. It just overwrites the >> first >> instruction of the old code with an unconditional branch to the new >> implementation. Thus, any code branching to the old location will >> still >> work. > > yes, that works so long as one has write access to the text section > (or the > code is otherwise in a

----- Original Message ----- > From: "Chandler Carruth" <chandlerc at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Philip Reames" > <listmail at philipreames.com>, "Duncan P. N. Exon Smith" > <dexonsmith at apple.com>, "Xinliang David Li"

On Jul 12, 2013, at 3:49 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > 3.2 Compile partitions independently > -------------------------------------- > > There are two camps: one camp advocate compiling partitions via multi-process, > the other one favor multi-thread. > > Inside Apple compiler teams, I'm the only one belong to the 1st comp. I think >

A third approach is to decouple the backend compilation and parallelism strategy from the partitioning. The partitioning can spits out partition BC files and some action records in some standard format. All of this can be fed into some driver tools that converts the compilation action file into make/build file of the underlying build system of your choice: 1) it can simply a compiler driver that