similar to: [LLVMdev] [LLVM Dev] [Discussion] Function-based parallel LLVM backend code generation

While I think the end goal you're describing is close to the correct one, I see the high-level strategy for getting there somewhat differently: 1) The code generators are only one collection of function passes that might be parallelized. Many others might also be parallelized profitably. The design for parallelism within LLVM's pass management infrastructure should be sufficiently generic

On Tue, Jul 16, 2013 at 3:33 AM, Wan, Xiaofei <xiaofei.wan at intel.com> wrote: > Hi, community: > > For the sake of our business need, I want to enable "Function-based parallel code generation" to boost up the compilation of single module, please see the details of the design and provide your feedbacks on below aspects, thanks! > 1. Is this idea the proper solution for

Please see Shuxin's proposal on "parallelizing post-IPO stage". It seems the two projects are related. Evan On Jul 16, 2013, at 3:33 AM, "Wan, Xiaofei" <xiaofei.wan at intel.com> wrote: > Hi, community: > > For the sake of our business need, I want to enable "Function-based parallel code generation" to boost up the compilation of single module,

Yes, the purpose is similar, we started this job from last year; But it Shuxin's solution is module based (correct me if I am wrong), we tried this solution and failed for many reasons, it is described in my design document https://docs.google.com/document/d/1QSkP6AumMCAVpgzwympD5pI3btPJt4SRgjY-vhyfySg/edit?usp=sharing we need discuss two solution and compare them, then adopt one solution

On 7/16/13 7:23 AM, Wan, Xiaofei wrote: > Yes, the purpose is similar, we started this job from last year; > But it Shuxin's solution is module based (correct me if I am wrong), we tried this solution and failed for many reasons, it is described in my design document > https://docs.google.com/document/d/1QSkP6AumMCAVpgzwympD5pI3btPJt4SRgjY-vhyfySg/edit?usp=sharing > > we need

-----Original Message----- From: Shuxin Yang [mailto:shuxin.llvm at gmail.com] Sent: Wednesday, July 17, 2013 1:50 AM To: Wan, Xiaofei Cc: Evan Cheng; Shuxin Yang; LLVM Developers Mailing List (llvmdev at cs.uiuc.edu) Subject: Re: [LLVMdev] [LLVM Dev] [Discussion] Function-based parallel LLVM backend code generation On 7/16/13 7:23 AM, Wan, Xiaofei wrote: > Yes, the purpose is similar, we

Hi, community: For the sake of our business need, I want to enable "Function-based parallel code generation" to boost up the compilation of single module, please see the details of the design and provide your feedbacks on below aspects, thanks 1. Is this idea the proper solution for my requirement 2. This new feature will be enabled by llc -thd=N and has no impact on

On Tue, Jul 16, 2013 at 1:18 PM, Xinliang David Li <xinliangli at gmail.com>wrote: > Ignoring FE time which can be fully parallelized and assuming 10% > compile time is spent in serial module passes, 25% time is spent in > CGSCC pass, the maximum speed up that can be gained by using function > level parallelism is less than 3x. Even adding support for parallel > compilation

HI, I am interested in whether LLVM bit-code is ready for a distribution format(stored in software distribution package); is it easy to revert LLVM IR to C/C++ source code like Java byte code? My understanding is that. 1. LLVM IR is more like assembly code, so it is not easy for reverse engineering. 2. If it is easy for reverse engineering, does it mean it is not suitable for distribution

On 7/16/2013 9:51 PM, Wan, Xiaofei wrote: > [Xiaofei] why? I don't understand it very well here, you mean it can > generate totally identical binaries as the original llc, including the > function order (function order may not affect code quality, but we > should make sure the output is same in each run)? Per <http://www-plan.cs.colorado.edu/diwan/asplos09.pdf>, function

LLVM IR represents higher level than assembler code, it keeps some names and it is easier to revert the IR to source code than a binary format. The main task of LLVM IR is code generation. I don't think adding obfuscation has particular worth, those who need it can use tools and approaches specifically aimed at obfuscation. Even simple rename of identifiers in source code makes C/C++ file

Hi, all: I am trying to test half float point support in llvm, I found clang can generate bitcode for __fp16, while llc can't generate code for it, the error message is like this LLVM ERROR: Cannot select: 0x26a68e0: i16 = fp32_to_fp16 0x26a67d8 [ORD=2] [ID=4] 0x26a67d8: f32,ch = CopyFromReg 0x2693060, 0x26a66d0 [ORD=2] [ID=3] 0x26a66d0: f32 = Register %vreg1 [ID=1] In function: test

On Tue, Jul 16, 2013 at 1:33 PM, Chandler Carruth <chandlerc at google.com> wrote: > On Tue, Jul 16, 2013 at 1:18 PM, Xinliang David Li <xinliangli at gmail.com> > wrote: >> >> Ignoring FE time which can be fully parallelized and assuming 10% >> compile time is spent in serial module passes, 25% time is spent in >> CGSCC pass, the maximum speed up that can

On Tue, Jul 16, 2013 at 1:37 PM, Xinliang David Li <xinliangli at gmail.com>wrote: > On Tue, Jul 16, 2013 at 1:33 PM, Chandler Carruth <chandlerc at google.com> > wrote: > > On Tue, Jul 16, 2013 at 1:18 PM, Xinliang David Li <xinliangli at gmail.com > > > > wrote: > >> > >> Ignoring FE time which can be fully parallelized and assuming 10%

Hello, This patch aims to improve compile time performance by increasing the SCEV vector size in LoopStrengthReduce. It is observed that the BaseRegs vector size is 4 in most cases, and elements are frequently copied when it is initialized as SmallVector<const SCEV *, 2> BaseRegs. Our benchmark results show that the compilation time performance improved by ~0.5%. Patch by Wan Xiaofei.

On Tue, Jul 16, 2013 at 1:40 PM, Chandler Carruth <chandlerc at google.com> wrote: > On Tue, Jul 16, 2013 at 1:37 PM, Xinliang David Li <xinliangli at gmail.com> > wrote: >> >> On Tue, Jul 16, 2013 at 1:33 PM, Chandler Carruth <chandlerc at google.com> >> wrote: >> > On Tue, Jul 16, 2013 at 1:18 PM, Xinliang David Li >> > <xinliangli

On Jul 17, 2013, at 4:29 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > On 7/17/13 4:12 PM, Nick Kledzik wrote: >> On Jul 14, 2013, at 7:07 PM, Andrew Trick <atrick at apple.com> wrote: >>> The partitioning should be deterministic. It’s just that the linker output now depends on the partitioning heuristics. As long that decision is based on the input (not the

On Thu, Jul 3, 2008 at 9:09 AM, Devang Patel <dpatel at apple.com> wrote: >> On Wed, Jul 2, 2008 at 7:00 PM, Mike Stump <mrs at apple.com> wrote: >>> If we apply their logic to llvm, we can dominate, if we just target 8 >>> cores. :-) > > Does this mean llvm can not dominate if llvm target 1 core machine > also ? Making an optimizer/code generator

On 7/17/13 12:35 PM, Diego Novillo wrote: > On Fri, Jul 12, 2013 at 3:49 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > >> 3. How to parallelize post-IPO stage >> ==================================== >> >> From 5k' high, the concept is very simple, just to >> step 1).divide the merged IR into small pieces, >> step 2).and compile

On Wed, Jul 17, 2013 at 1:06 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > > On 7/17/13 12:35 PM, Diego Novillo wrote: >> >> On Fri, Jul 12, 2013 at 3:49 PM, Shuxin Yang <shuxin.llvm at gmail.com> >> wrote: >> >>> 3. How to parallelize post-IPO stage >>> ==================================== >>> >>> From 5k'