[LLVMdev] LLVMdev Digest, Vol 131, Issue 56
Jyoti
jyoti.yalamanchili at gmail.com
Thu May 14 15:02:07 PDT 2015
Hi James,
Thanks for your prompt reply. I will add the pattern and send out for
review.
Thanks.
-Jyoti
>Hi Jyoti,
>
>The first version doesn?t need a SMUL_LOHI, as it?s only doing a 32-bit
multiply. The results of that 32-bit multiply are fed into the 64-bit ADD.
>
>The second one is doing a 64-bit multiply. This is expanded to a
SMUL_LOHI, and is peepholed by ISelLowering.
>
>It looks simply like whoever wrote this peephole only considered that one
version and didn?t consider the more canonical pattern (with a 32-bit
multiply).
>
>The place to fix seems to be ARMISelLowering::7949 (AddCombineTo64BitMLAL)
- adding a new pattern for that to detect.
>Cheers,
>
>James
On Thu, May 14, 2015 at 9:57 PM, <llvmdev-request at cs.uiuc.edu> wrote:
> 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. LLVM commit rights (OpenMP runtime) (Cownie, James H)
> 2. Re: [Openmp-dev] LLVM commit rights (OpenMP runtime) (Hal Finkel)
> 3. Re: RFC: Convergent attribute (Mehdi Amini)
> 4. [ARM backend] SMLAL issue (Jyoti Rajendra Allur)
> 5. Re: 3.6.1 -rc1 has been tagged. Testing begins. (Renato Golin)
> 6. Re: RFC: Convergent attribute (Mehdi Amini)
> 7. Re: [WinEH] A hiccup for the Windows C++ exception handling
> (Reid Kleckner)
> 8. Re: [ARM backend] SMLAL issue (James Molloy)
> 9. Re: RFC: ThinLTO Impementation Plan (Xinliang David Li)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 14 May 2015 15:24:03 +0000
> From: "Cownie, James H" <james.h.cownie at intel.com>
> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>,
> "openmp-dev at dcs-maillist2.engr.illinois.edu"
> <openmp-dev at dcs-maillist2.engr.illinois.edu>
> Cc: "Peyton, Jonathan L" <jonathan.l.peyton at intel.com>
> Subject: [LLVMdev] LLVM commit rights (OpenMP runtime)
> Message-ID:
> <
> 397D95928DECEF49983F5B237627E97841C62F0F at IRSMSX108.ger.corp.intel.com>
>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi All,
>
> I have been involved with the LLVM OpenMP runtime since it was first
> committed
> to the LLVM repository, and have LLVM commit rights. However, my role
> inside
> Intel is changing, and I believe that it therefore makes sense for someone
> else
> to have commit rights, and for mine to be revoked.
>
> I would therefore like to request that Johnny Peyton be given commit
> rights.
> He has been doing a lot of work on the LLVM OpenMP runtime (as can be seen
> in
> the mail chains), and if he had rights that would avoid some of the delays
> we've
> seen recently when Andrey has been out for Russian public holidays.
>
> I have really enjoyed working with the LLVM team, and will still be here,
> just with
> a less formal relationship inside Intel.
>
> -- Jim
>
> James Cownie <james.h.cownie at intel.com>
> SSG/DPD/TCAR (Technical Computing, Analyzers and Runtimes)
> Tel: +44 117 9071438
>
> ---------------------------------------------------------------------
> Intel Corporation (UK) Limited
> Registered No. 1134945 (England)
> Registered Office: Pipers Way, Swindon SN3 1RJ
> VAT No: 860 2173 47
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 14 May 2015 10:32:13 -0500
> From: Hal Finkel <hfinkel at anl.gov>
> To: James H Cownie <james.h.cownie at intel.com>
> Cc: openmp-dev at dcs-maillist2.engr.illinois.edu, LLVM Developers
> Mailing List <llvmdev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] [Openmp-dev] LLVM commit rights (OpenMP
> runtime)
> Message-ID:
> <4797056.576.1431617533573.JavaMail.javamailuser at localhost>
> Content-Type: text/plain; charset="utf-8"
>
> ----- Original Message -----
> > From: "James H Cownie" <james.h.cownie at intel.com>
> > To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>,
> openmp-dev at dcs-maillist2.engr.illinois.edu
> > Sent: Thursday, May 14, 2015 10:24:03 AM
> > Subject: [Openmp-dev] LLVM commit rights (OpenMP runtime)
> >
> > Hi All,
> >
> > I have been involved with the LLVM OpenMP runtime since it was first
> > committed
> > to the LLVM repository, and have LLVM commit rights. However, my role
> > inside
> > Intel is changing, and I believe that it therefore makes sense for
> > someone else
> > to have commit rights, and for mine to be revoked.
> >
> > I would therefore like to request that Johnny Peyton be given commit
>
> Johnny has been a regular contributor, he simply needs to submit a request
> for commit access as documented here:
> http://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access
>
> > rights.
> > He has been doing a lot of work on the LLVM OpenMP runtime (as can be
> > seen in
> > the mail chains), and if he had rights that would avoid some of the
> > delays we've
> > seen recently when Andrey has been out for Russian public holidays.
> >
> > I have really enjoyed working with the LLVM team, and will still be
> > here, just with
> > a less formal relationship inside Intel.
>
> You've made a valuable contribution to the LLVM project, and I wish you
> the best of luck with your future projects. I hope you'll stick around on
> the mailing lists to provide advice and opinions.
>
> -Hal
>
> >
> > -- Jim
> >
> > James Cownie <james.h.cownie at intel.com>
> > SSG/DPD/TCAR (Technical Computing, Analyzers and Runtimes)
> > Tel: +44 117 9071438
> >
> > ---------------------------------------------------------------------
> > Intel Corporation (UK) Limited
> > Registered No. 1134945 (England)
> > Registered Office: Pipers Way, Swindon SN3 1RJ
> > VAT No: 860 2173 47
> >
> > This e-mail and any attachments may contain confidential material for
> > the sole use of the intended recipient(s). Any review or distribution
> > by others is strictly prohibited. If you are not the intended
> > recipient, please contact the sender and delete all copies.
> >
> >
> > _______________________________________________
> > Openmp-dev mailing list
> > Openmp-dev at dcs-maillist2.engr.illinois.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/openmp-dev
> >
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 14 May 2015 08:33:32 -0700
> From: Mehdi Amini <mehdi.amini at apple.com>
> To: Philip Reames <listmail at philipreames.com>
> Cc: Lista LLVM-dev <llvmdev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] RFC: Convergent attribute
> Message-ID: <7B862523-9330-4F84-9011-DB0FF8830ADD at apple.com>
> Content-Type: text/plain; charset=utf-8
>
>
> > On May 13, 2015, at 6:00 PM, Philip Reames <listmail at philipreames.com>
> wrote:
> >
> > LGTM. Please put pretty much everything in this email into a
> documentation page. Doesn't have to be LangRef, but definitely something
> linked from there.
> >
> > Also, it would be good to explicitly say that this is working around a
> limitation in the register allocator. Just because it's a limitation which
> would be very hard to address doesn't mean it isn't a limitation. :)
>
> Only a subset of the problem (architecture specific) can be addressed by a
> ?clever? register allocator I think. The general problem goes beyond.
>
> ?
> Mehdi
>
> >
> > Philip
> >
> > On 05/13/2015 01:17 PM, Owen Anderson wrote:
> >> Below is a proposal for a new "convergent" intrinsic attribute and
> MachineInstr property, needed for correctly modeling many SPMD/SIMT
> programming models in LLVM. Comments and feedback welcome.
> >>
> >> ?Owen
> >>
> >>
> >>
> >>
> >>
> >> In order to make LLVM more suitable for programming models variously
> called SPMD
> >> and SIMT, we would like to propose a new intrinsic and MachineInstr
> annotation
> >> called "convergent", which will be used to impose certain control flow
> and/or
> >> code motion constraints that are necessary for the correct compilation
> of some
> >> common constructs in these programming models.
> >>
> >> Our proposal strives to define the semantics of these annotations
> *without*
> >> introducing a definition of SPMD/SIMT programming models into LLVM IR.
> Rather,
> >> the properties that must be preserved are specified purely in terms of
> single
> >> thread semantics. This allows pass authors to reason about the
> constraints
> >> without having to consider alternative programming models. The
> downside to
> >> this approach is that the motivation and necessity of these constraints
> in not
> >> easily understood without understanding the programming model from
> which they
> >> derive.
> >>
> >> *** WHAT ***
> >>
> >> (Thanks to Phil Reames for input on this definition.)
> >>
> >> An operation marked convergent may be transformed or moved within the
> program
> >> if and only the post-transform placement of the convergent operation is
> >> control equivalent (A dominated B, B post-dominates A, or vice-versa) to
> >> its original position.
> >>
> >> This definition is overly strict with respect to some SPMD/SIMT models,
> >> but cannot be relaxed without introducing a specific model into LLVM
> IR. We
> >> believe it is important for LLVM itself to remain agnostic to any
> specific
> >> model. This allows core passes to preserve correctness for stricter
> models,
> >> while more relaxed models can implement additional transforms that use
> >> weaker constraints on top of core LLVM.
> >>
> >> *** HOW ***
> >>
> >> Once the attribute has been added, we anticipate the following changes
> to
> >> optimization passes will be required:
> >> - Restrict Sink and MachineSink for convergent operations
> >> - Disabling PRE for convergent operations
> >> - Disabling jump threading of convergent operations
> >> - Auditing SimplifyCFG for additional transforms that break
> convergent guarantees
> >>
> >> *** WHY ***
> >>
> >> SPMD/SIMT programming models are a family of related programming models
> in
> >> which multiple threads execute in a per-instruction lockstep fashion.
> >> Predication is typically used to implement acyclic control flow that
> would
> >> otherwise diverge the PC address of the lockstep threads.
> >>
> >> In these models, each thread's register set is typically indepedent,
> but there
> >> exist a small number of important circumstances in which a thread may
> access
> >> register storage from one of its lockstep neighbors. Examples include
> gradient
> >> computation for texture lookups, as well a cross-thread broadcast and
> shuffle
> >> operations.
> >>
> >> These operations that provide access to another thread's register
> storage pose
> >> a particular challenge to the compiler, particularly when combined with
> the
> >> use of predication for control flow. Consider the following example:
> >>
> >> // texture lookup that computes gradient of r0, last use of r0
> >> r1 = texture2D(..., r0, ...)
> >> if (...) {
> >> // r0 used as temporary here
> >> r0 = ...
> >> r2 = r0 + ...
> >> } else {
> >> // only use of r1
> >> r2 = r1 + ...
> >> }
> >>
> >> In this example, various optimizations might try to sink the texture2D
> operation
> >> into the else block, like so:
> >>
> >> if (...) {
> >> r0 = ...
> >> r2 = r0 + ...
> >> } else {
> >> r1 = texture2D(..., r0, ...)
> >> r2 = r1 + ...
> >> }
> >>
> >> At this point, it starts to become clear that a problem can occur when
> two
> >> neighbor threads want to take different paths through the if-else
> construct.
> >> Logically, the thread that wishes to execute the texture2D races with
> its
> >> neighbor to reads the neighbor's value of r0 before it gets overridden.
> >>
> >> In most SPMD/SIMT implementations, the fallout of this races is exposed
> via
> >> the predicated expression of acyclic control flow:
> >>
> >> pred0 <- cmp ...
> >> if (pred0) r0 = ...
> >> if (pred0) r2 = r0 + ...
> >> if (!pred0) r1 = texture2D(..., r0, ...)
> >> if (!pred0) r2 = r1 + ...
> >>
> >> If thread 0 takes the else path and perform the texture2D operation, but
> >> its neighbor thread 1 takes the then branch, then the texture2D will
> fail
> >> because thread 1 has already overwritten its value of r0 before thread
> 0 has
> >> a chance to read it.
> >>
> >>
> >>
> >> _______________________________________________
> >> 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: 4
> Date: Thu, 14 May 2015 15:36:33 +0000 (GMT)
> From: Jyoti Rajendra Allur <jyoti.allur at samsung.com>
> To: llvmdev at cs.uiuc.edu, t.p.northover at gmail.com, james.molloy at arm.com
> Subject: [LLVMdev] [ARM backend] SMLAL issue
> Message-ID:
> <1106717447.198031431617793195.JavaMail.weblogic at ep2mlwas08b>
> Content-Type: text/plain; charset=windows-1252
>
> Hi Tim/James,
> In the following code, MUL, ADDS, ADC are combined to SMLAL only if 'b'
> and 'c' are promoted to long long type during multiplication. Shouldn't
> they be allowed to be combined to SMLAL
> even in the code as is without promoting b and c to long long type?
>
> I found the reason for not combining to SMAL to be this, ADDS operand 0
> has opcode not set as ISD::SMUL_LOHI even though operand 0 ie., R2 is a
> result of SMULBB as seen in the assembly.
>
> long long
> foo (long long a, int b, int c)
> {
> return a + b * c; ===> return a + (long long)b * (long long)c;
>
> }
> ldrb r2, [r2]
> ldrb r3, [r3]
> smulbb r2, r3, r2
> adds r0, r2, r0
> adc r1, r1, #0
> bx lr
>
> I have already checked in combine function in DAG combiner and visitADDC,
> ADDS node operand0 's opcode is not set to ISD::SMUL_LOHI. Only when b and
> c are typecasted to long long, operand0 opcode is set to ISD::SMUL_LOHI
> Is this a likely bug, if not is there a specific reason for designing it
> this way ?
>
>
> Regards,
> Jyoti Allur
>
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 14 May 2015 16:49:56 +0100
> From: Renato Golin <renato.golin at linaro.org>
> To: Tom Stellard <tom at stellard.net>
> Cc: Clang Dev <cfe-dev at cs.uiuc.edu>, LLVM Dev <llvmdev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] 3.6.1 -rc1 has been tagged. Testing begins.
> Message-ID:
> <
> CAMSE1kdv8O7HSBxLZMtddyiYZwxzPh7BZDJ3qTufu0W39MkkUQ at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On 13 May 2015 at 18:47, Renato Golin <renato.golin at linaro.org> wrote:
> > The binary was uploaded into the server, in case someone wants to have
> > a look, but I'll have to fix my environment for the final release.
>
> So, I've uploaded a new binary, built with a stable Debian, GCC 4.9.2, etc.
>
> I'm seeing two execution failures in the test-suite:
>
> MultiSource/Benchmarks/MiBench/consumer-typeset/consumer-typeset
> MultiSource/UnitTests/C++11/frame_layout/frame_layout
>
> Investigating...
>
> cheers,
> --renato
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 14 May 2015 08:50:49 -0700
> From: Mehdi Amini <mehdi.amini at apple.com>
> To: Philip Reames <listmail at philipreames.com>
> Cc: Lista LLVM-dev <llvmdev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] RFC: Convergent attribute
> Message-ID: <5AEA9F2F-14DE-4063-AFBC-1E67061DE160 at apple.com>
> Content-Type: text/plain; charset=utf-8
>
>
> > On May 14, 2015, at 8:33 AM, Mehdi Amini <mehdi.amini at apple.com> wrote:
> >
> >>
> >> On May 13, 2015, at 6:00 PM, Philip Reames <listmail at philipreames.com>
> wrote:
> >>
> >> LGTM. Please put pretty much everything in this email into a
> documentation page. Doesn't have to be LangRef, but definitely something
> linked from there.
> >>
> >> Also, it would be good to explicitly say that this is working around a
> limitation in the register allocator. Just because it's a limitation which
> would be very hard to address doesn't mean it isn't a limitation. :)
> >
> > Only a subset of the problem (architecture specific) can be addressed by
> a ?clever? register allocator I think. The general problem goes beyond.
>
> Thinking more about it, the example I had in mind was wrong and I can?t
> find one right now, I retract what I said :)
>
> ?
> Mehdi
>
>
> >>
> >> Philip
> >>
> >> On 05/13/2015 01:17 PM, Owen Anderson wrote:
> >>> Below is a proposal for a new "convergent" intrinsic attribute and
> MachineInstr property, needed for correctly modeling many SPMD/SIMT
> programming models in LLVM. Comments and feedback welcome.
> >>>
> >>> ?Owen
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> In order to make LLVM more suitable for programming models variously
> called SPMD
> >>> and SIMT, we would like to propose a new intrinsic and MachineInstr
> annotation
> >>> called "convergent", which will be used to impose certain control flow
> and/or
> >>> code motion constraints that are necessary for the correct compilation
> of some
> >>> common constructs in these programming models.
> >>>
> >>> Our proposal strives to define the semantics of these annotations
> *without*
> >>> introducing a definition of SPMD/SIMT programming models into LLVM
> IR. Rather,
> >>> the properties that must be preserved are specified purely in terms of
> single
> >>> thread semantics. This allows pass authors to reason about the
> constraints
> >>> without having to consider alternative programming models. The
> downside to
> >>> this approach is that the motivation and necessity of these
> constraints in not
> >>> easily understood without understanding the programming model from
> which they
> >>> derive.
> >>>
> >>> *** WHAT ***
> >>>
> >>> (Thanks to Phil Reames for input on this definition.)
> >>>
> >>> An operation marked convergent may be transformed or moved within the
> program
> >>> if and only the post-transform placement of the convergent operation is
> >>> control equivalent (A dominated B, B post-dominates A, or vice-versa)
> to
> >>> its original position.
> >>>
> >>> This definition is overly strict with respect to some SPMD/SIMT models,
> >>> but cannot be relaxed without introducing a specific model into LLVM
> IR. We
> >>> believe it is important for LLVM itself to remain agnostic to any
> specific
> >>> model. This allows core passes to preserve correctness for stricter
> models,
> >>> while more relaxed models can implement additional transforms that use
> >>> weaker constraints on top of core LLVM.
> >>>
> >>> *** HOW ***
> >>>
> >>> Once the attribute has been added, we anticipate the following changes
> to
> >>> optimization passes will be required:
> >>> - Restrict Sink and MachineSink for convergent operations
> >>> - Disabling PRE for convergent operations
> >>> - Disabling jump threading of convergent operations
> >>> - Auditing SimplifyCFG for additional transforms that break
> convergent guarantees
> >>>
> >>> *** WHY ***
> >>>
> >>> SPMD/SIMT programming models are a family of related programming
> models in
> >>> which multiple threads execute in a per-instruction lockstep fashion.
> >>> Predication is typically used to implement acyclic control flow that
> would
> >>> otherwise diverge the PC address of the lockstep threads.
> >>>
> >>> In these models, each thread's register set is typically indepedent,
> but there
> >>> exist a small number of important circumstances in which a thread may
> access
> >>> register storage from one of its lockstep neighbors. Examples include
> gradient
> >>> computation for texture lookups, as well a cross-thread broadcast and
> shuffle
> >>> operations.
> >>>
> >>> These operations that provide access to another thread's register
> storage pose
> >>> a particular challenge to the compiler, particularly when combined
> with the
> >>> use of predication for control flow. Consider the following example:
> >>>
> >>> // texture lookup that computes gradient of r0, last use of r0
> >>> r1 = texture2D(..., r0, ...)
> >>> if (...) {
> >>> // r0 used as temporary here
> >>> r0 = ...
> >>> r2 = r0 + ...
> >>> } else {
> >>> // only use of r1
> >>> r2 = r1 + ...
> >>> }
> >>>
> >>> In this example, various optimizations might try to sink the texture2D
> operation
> >>> into the else block, like so:
> >>>
> >>> if (...) {
> >>> r0 = ...
> >>> r2 = r0 + ...
> >>> } else {
> >>> r1 = texture2D(..., r0, ...)
> >>> r2 = r1 + ...
> >>> }
> >>>
> >>> At this point, it starts to become clear that a problem can occur when
> two
> >>> neighbor threads want to take different paths through the if-else
> construct.
> >>> Logically, the thread that wishes to execute the texture2D races with
> its
> >>> neighbor to reads the neighbor's value of r0 before it gets overridden.
> >>>
> >>> In most SPMD/SIMT implementations, the fallout of this races is
> exposed via
> >>> the predicated expression of acyclic control flow:
> >>>
> >>> pred0 <- cmp ...
> >>> if (pred0) r0 = ...
> >>> if (pred0) r2 = r0 + ...
> >>> if (!pred0) r1 = texture2D(..., r0, ...)
> >>> if (!pred0) r2 = r1 + ...
> >>>
> >>> If thread 0 takes the else path and perform the texture2D operation,
> but
> >>> its neighbor thread 1 takes the then branch, then the texture2D will
> fail
> >>> because thread 1 has already overwritten its value of r0 before thread
> 0 has
> >>> a chance to read it.
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> 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
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 14 May 2015 09:12:10 -0700
> From: Reid Kleckner <rnk at google.com>
> To: "Kaylor, Andrew" <andrew.kaylor at intel.com>
> Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] [WinEH] A hiccup for the Windows C++ exception
> handling
> Message-ID:
> <CACs=tyKxsnELWEz=-
> EMKaBqc0Uw-yXxxwE6BB4BdNP2GMyf3jw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Wed, May 13, 2015 at 4:37 PM, Kaylor, Andrew <andrew.kaylor at intel.com>
> wrote:
>
> > I made some progress this afternoon. I now have a set of changes in my
> > local sandbox that allows clang to pass all of the tests in the suite
> I?ve
> > been using to exercise this code.
> >
> >
> >
> > How do you feel about working these changes into trunk to establish a
> > working baseline, even knowing that parts of this are going to be
> > redesigned?
> >
>
> I guess I'm kind of ambivalent about continuing in the current direction.
> It doesn't hurt, but if it provides someone with basic functionality for
> now, then that's OK. On the other hand, the tests won't be particularly
> valuable because Clang is going to emit new LLVM IR, so they'll need to be
> redone.
>
> I also think that, given that the rewrite will take at least a month, we
> should turn MSVC C++ exceptions off by default in Clang until it's ready.
> We need some hidden flag that isn't /EHs. I'm already tired of getting bug
> reports along the lines of "clang crashed while compiling MSVC-style
> exceptions". Of course, the user can't tell from the crash that the
> workaround is just "turn off exceptions until they work". =/
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20150514/f5f52f1e/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 8
> Date: Thu, 14 May 2015 17:16:01 +0100
> From: James Molloy <James.Molloy at arm.com>
> To: "jyoti.allur at samsung.com" <jyoti.allur at samsung.com>
> Cc: "llvmdev at cs.uiuc.edu" <llvmdev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] [ARM backend] SMLAL issue
> Message-ID: <A629EA4C-18FA-4670-AFD8-B065E8C291D9 at arm.com>
> Content-Type: text/plain; charset=WINDOWS-1252
>
> Hi Jyoti,
>
> The first version doesn?t need a SMUL_LOHI, as it?s only doing a 32-bit
> multiply. The results of that 32-bit multiply are fed into the 64-bit ADD.
>
> The second one is doing a 64-bit multiply. This is expanded to a
> SMUL_LOHI, and is peepholed by ISelLowering.
>
> It looks simply like whoever wrote this peephole only considered that one
> version and didn?t consider the more canonical pattern (with a 32-bit
> multiply).
>
> The place to fix seems to be ARMISelLowering::7949 (AddCombineTo64BitMLAL)
> - adding a new pattern for that to detect.
>
> Cheers,
>
> James
>
> On 14 May 2015, at 16:36, Jyoti Rajendra Allur <jyoti.allur at samsung.com>
> wrote:
>
> > Hi Tim/James,
> > In the following code, MUL, ADDS, ADC are combined to SMLAL only if 'b'
> and 'c' are promoted to long long type during multiplication. Shouldn't
> they be allowed to be combined to SMLAL
> > even in the code as is without promoting b and c to long long type?
> >
> > I found the reason for not combining to SMAL to be this, ADDS operand 0
> has opcode not set as ISD::SMUL_LOHI even though operand 0 ie., R2 is a
> result of SMULBB as seen in the assembly.
> >
> > long long
> > foo (long long a, int b, int c)
> > {
> > return a + b * c; ===> return a + (long long)b * (long long)c;
> >
> > }
> > ldrb r2, [r2]
> > ldrb r3, [r3]
> > smulbb r2, r3, r2
> > adds r0, r2, r0
> > adc r1, r1, #0
> > bx lr
> >
> > I have already checked in combine function in DAG combiner and
> visitADDC, ADDS node operand0 's opcode is not set to ISD::SMUL_LOHI. Only
> when b and c are typecasted to long long, operand0 opcode is set to
> ISD::SMUL_LOHI
> > Is this a likely bug, if not is there a specific reason for designing it
> this way ?
> >
> >
> > Regards,
> > Jyoti Allur
>
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
> Registered in England & Wales, Company No: 2557590
> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
> Registered in England & Wales, Company No: 2548782
>
>
>
>
> ------------------------------
>
> Message: 9
> Date: Thu, 14 May 2015 09:26:53 -0700
> From: Xinliang David Li <xinliangli at gmail.com>
> To: Teresa Johnson <tejohnson at google.com>
> Cc: "<llvmdev at cs.uiuc.edu> List" <llvmdev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] RFC: ThinLTO Impementation Plan
> Message-ID:
> <
> CALRgJCNmJrvxArwGBKgnVDuh81jZep1QbLQ9T_XjN9cgYJxs7A at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> The design objective is to make thinLTO mostly transparent to binutil tools
> to enable easy integration with any build system in the wild.
> 'Pass-through' mode with 'ld -r' instead of the partial LTO mode is
> another reason.
>
> David
>
> On Thu, May 14, 2015 at 7:30 AM, Teresa Johnson <tejohnson at google.com>
> wrote:
>
> > On Thu, May 14, 2015 at 7:22 AM, Eric Christopher <echristo at gmail.com>
> > wrote:
> > > So, what Alex is saying is that we have these tools as well and they
> > > understand bitcode just fine, as well as every object format - not just
> > ELF.
> > > :)
> >
> > Right, there are also LLVM specific versions (llvm-ar, llvm-nm) that
> > handle bitcode similarly to the way the standard tool + plugin does.
> > But the goal we are trying to achieve is to allow the standard system
> > versions of the tools to handle these files without requiring a
> > plugin. I know the LLVM tool handles other object formats, but I'm not
> > sure how that helps here? We're not planning to replace those tools,
> > just allow the standard system versions to handle the intermediate
> > objects produced by ThinLTO.
> >
> > Thanks,
> > Teresa
> >
> > >
> > > -eric
> > >
> > >
> > > On Thu, May 14, 2015, 6:55 AM Teresa Johnson <tejohnson at google.com>
> > wrote:
> > >>
> > >> On Wed, May 13, 2015 at 11:23 PM, Xinliang David Li
> > >> <xinliangli at gmail.com> wrote:
> > >> >
> > >> >
> > >> > On Wed, May 13, 2015 at 10:46 PM, Alex Rosenberg <
> alexr at leftfield.org
> > >
> > >> > wrote:
> > >> >>
> > >> >> "ELF-wrapped bitcode" seems potentially controversial to me.
> > >> >>
> > >> >> What about ar, nm, and various ld implementations adds this
> > >> >> requirement?
> > >> >> What about the LLVM implementations of these tools is lacking?
> > >> >
> > >> >
> > >> > Sorry I can not parse your questions properly. Can you make it
> > clearer?
> > >>
> > >> Alex is asking what the issue is with ar, nm, ld -r and regular
> > >> bitcode that makes using elf-wrapped bitcode easier.
> > >>
> > >> The issue is that generally you need to provide a plugin to these
> > >> tools in order for them to understand and handle bitcode files. We'd
> > >> like standard tools to work without requiring a plugin as much as
> > >> possible. And in some cases we want them to be handled different than
> > >> the way bitcode files are handled with the plugin.
> > >>
> > >> nm: Without a plugin, normal bitcode files are inscrutable. When
> > >> provided the gold plugin it can emit the symbols.
> > >>
> > >> ar: Without a plugin, it will create an archive of bitcode files, but
> > >> without an index, so it can't be handled by the linker even with a
> > >> plugin on an -flto link. When ar is provided the gold plugin it does
> > >> create an index, so the linker + gold plugin handle it appropriately
> > >> on an -flto link.
> > >>
> > >> ld -r: Without a plugin, fails when provided bitcode inputs. When
> > >> provided the gold plugin, it handles them but compiles them all the
> > >> way through to ELF executable instructions via a partial LTO link.
> > >> This is where we would like to differ in behavior (while also not
> > >> requiring a plugin) with ELF-wrapped bitcode: we would like the ld -r
> > >> output file to still contain ELF-wrapped bitcode, delaying the LTO
> > >> until the full link step.
> > >>
> > >> Let me know if that helps address your concerns.
> > >>
> > >> Thanks,
> > >> Teresa
> > >>
> > >> >
> > >> > David
> > >> >
> > >> >>
> > >> >>
> > >> >> Alex
> > >> >>
> > >> >> > On May 13, 2015, at 7:44 PM, Teresa Johnson <
> tejohnson at google.com>
> > >> >> > wrote:
> > >> >> >
> > >> >> > I've included below an RFC for implementing ThinLTO in LLVM,
> > looking
> > >> >> > forward to feedback and questions.
> > >> >> > Thanks!
> > >> >> > Teresa
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> > RFC to discuss plans for implementing ThinLTO upstream.
> Background
> > >> >> > can
> > >> >> > be found in slides from EuroLLVM 2015:
> > >> >> >
> > >> >> >
> > >> >> >
> > https://drive.google.com/open?id=0B036uwnWM6RWWER1ZEl5SUNENjQ&authuser=0
> )
> > >> >> > As described in the talk, we have a prototype implementation, and
> > >> >> > would like to start staging patches upstream. This RFC describes
> a
> > >> >> > breakdown of the major pieces. We would like to commit upstream
> > >> >> > gradually in several stages, with all functionality off by
> default.
> > >> >> > The core ThinLTO importing support and tuning will require
> frequent
> > >> >> > change and iteration during testing and tuning, and for that part
> > we
> > >> >> > would like to commit rapidly (off by default). See the proposed
> > >> >> > staged
> > >> >> > implementation described in the Implementation Plan section.
> > >> >> >
> > >> >> >
> > >> >> > ThinLTO Overview
> > >> >> > ==============
> > >> >> >
> > >> >> > See the talk slides linked above for more details. The following
> > is a
> > >> >> > high-level overview of the motivation.
> > >> >> >
> > >> >> > Cross Module Optimization (CMO) is an effective means for
> improving
> > >> >> > runtime performance, by extending the scope of optimizations
> across
> > >> >> > source module boundaries. Without CMO, the compiler is limited to
> > >> >> > optimizing within the scope of single source modules. Two
> solutions
> > >> >> > for enabling CMO are Link-Time Optimization (LTO), which is
> > currently
> > >> >> > supported in LLVM and GCC, and Lightweight-Interprocedural
> > >> >> > Optimization (LIPO). However, each of these solutions has
> > limitations
> > >> >> > that prevent it from being enabled by default. ThinLTO is a new
> > >> >> > approach that attempts to address these limitations, with a goal
> of
> > >> >> > being enabled more broadly. ThinLTO is designed with many of the
> > same
> > >> >> > principals as LIPO, and therefore its advantages, without any of
> > its
> > >> >> > inherent weakness. Unlike in LIPO where the module group decision
> > is
> > >> >> > made at profile training runtime, ThinLTO makes the decision at
> > >> >> > compile time, but in a lazy mode that facilitates large scale
> > >> >> > parallelism. The serial linker plugin phase is designed to be
> razor
> > >> >> > thin and blazingly fast. By default this step only does minimal
> > >> >> > preparation work to enable the parallel lazy importing performed
> > >> >> > later. ThinLTO aims to be scalable like a regular O2 build,
> > enabling
> > >> >> > CMO on machines without large memory configurations, while also
> > >> >> > integrating well with distributed build systems. Results from
> early
> > >> >> > prototyping on SPEC cpu2006 C++ benchmarks are in line with
> > >> >> > expectations that ThinLTO can scale like O2 while enabling much
> of
> > >> >> > the
> > >> >> > CMO performed during a full LTO build.
> > >> >> >
> > >> >> >
> > >> >> > A ThinLTO build is divided into 3 phases, which are referred to
> in
> > >> >> > the
> > >> >> > following implementation plan:
> > >> >> >
> > >> >> > phase-1: IR and Function Summary Generation (-c compile)
> > >> >> > phase-2: Thin Linker Plugin Layer (thin archive linker step)
> > >> >> > phase-3: Parallel Backend with Demand-Driven Importing
> > >> >> >
> > >> >> >
> > >> >> > Implementation Plan
> > >> >> > ================
> > >> >> >
> > >> >> > This section gives a high-level breakdown of the ThinLTO support
> > that
> > >> >> > will be added, in roughly the order that the patches would be
> > staged.
> > >> >> > The patches are divided into three stages. The first stage
> > contains a
> > >> >> > minimal amount of preparation work that is not ThinLTO-specific.
> > The
> > >> >> > second stage contains most of the infrastructure for ThinLTO,
> which
> > >> >> > will be off by default. The third stage includes
> > >> >> > enhancements/improvements/tunings that can be performed after the
> > >> >> > main
> > >> >> > ThinLTO infrastructure is in.
> > >> >> >
> > >> >> > The second and third implementation stages will initially be very
> > >> >> > volatile, requiring a lot of iterations and tuning with large
> apps
> > to
> > >> >> > get stabilized. Therefore it will be important to do fast commits
> > for
> > >> >> > these implementation stages.
> > >> >> >
> > >> >> >
> > >> >> > 1. Stage 1: Preparation
> > >> >> > -------------------------------
> > >> >> >
> > >> >> > The first planned sets of patches are enablers for ThinLTO work:
> > >> >> >
> > >> >> >
> > >> >> > a. LTO directory structure:
> > >> >> >
> > >> >> > Restructure the LTO directory to remove circular dependence when
> > >> >> > ThinLTO pass added. Because ThinLTO is being implemented as a SCC
> > >> >> > pass
> > >> >> > within Transforms/IPO, and leverages the LTOModule class for
> > linking
> > >> >> > in functions from modules, IPO then requires the LTO library.
> This
> > >> >> > creates a circular dependence between LTO and IPO. To break that,
> > we
> > >> >> > need to split the lib/LTO directory/library into lib/LTO/CodeGen
> > and
> > >> >> > lib/LTO/Module, containing LTOCodeGenerator and LTOModule,
> > >> >> > respectively. Only LTOCodeGenerator has a dependence on IPO,
> > removing
> > >> >> > the circular dependence.
> > >> >> >
> > >> >> >
> > >> >> > b. ELF wrapper generation support:
> > >> >> >
> > >> >> > Implement ELF wrapped bitcode writer. In order to more easily
> > >> >> > interact
> > >> >> > with tools such as $AR, $NM, and ?$LD -r? we plan to emit the
> > phase-1
> > >> >> > bitcode wrapped in ELF via the .llvmbc section, along with a
> symbol
> > >> >> > table. The goal is both to interact with these tools without
> > >> >> > requiring
> > >> >> > a plugin, and also to avoid doing partial LTO/ThinLTO across
> files
> > >> >> > linked with ?$LD -r? (i.e. the resulting object file should still
> > >> >> > contain ELF-wrapped bitcode to enable ThinLTO at the full link
> > step).
> > >> >> > I will send a separate design document for these changes, but the
> > >> >> > following is a high-level overview.
> > >> >> >
> > >> >> > Support was added to LLVM for reading ELF-wrapped bitcode
> > >> >> > (http://reviews.llvm.org/rL218078), but there does not yet exist
> > >> >> > support in LLVM/Clang for emitting bitcode wrapped in ELF. I plan
> > to
> > >> >> > add support for optionally generating bitcode in an ELF file
> > >> >> > containing a single .llvmbc section holding the bitcode.
> > >> >> > Specifically,
> > >> >> > the patch would add new options ?emit-llvm-bc-elf? (object file)
> > and
> > >> >> > corresponding ?emit-llvm-elf? (textual assembly code equivalent).
> > >> >> > Eventually these would be automatically triggered under
> ?-fthinlto
> > >> >> > -c?
> > >> >> > and ?-fthinlto -S?, respectively.
> > >> >> >
> > >> >> > Additionally, a symbol table will be generated in the ELF file,
> > >> >> > holding the function symbols within the bitcode. This facilitates
> > >> >> > handling archives of the ELF-wrapped bitcode created with $AR,
> > since
> > >> >> > the archive will have a symbol table as well. The archive symbol
> > >> >> > table
> > >> >> > enables gold to extract and pass to the plugin the constituent
> > >> >> > ELF-wrapped bitcode files. To support the concatenated llvmbc
> > section
> > >> >> > generated by ?$LD -r?, some handling needs to be added to gold
> and
> > to
> > >> >> > the backend driver to process each original module?s bitcode.
> > >> >> >
> > >> >> > The function index/summary will later be added as a special ELF
> > >> >> > section alongside the .llvmbc sections.
> > >> >> >
> > >> >> >
> > >> >> > 2. Stage 2: ThinLTO Infrastructure
> > >> >> > ----------------------------------------------
> > >> >> >
> > >> >> > The next set of patches adds the base implementation of the
> ThinLTO
> > >> >> > infrastructure, specifically those required to make ThinLTO
> > >> >> > functional
> > >> >> > and generate correct but not necessarily high-performing
> binaries.
> > It
> > >> >> > also does not include support to make debug support under -g
> > >> >> > efficient
> > >> >> > with ThinLTO.
> > >> >> >
> > >> >> >
> > >> >> > a. Clang/LLVM/gold linker options:
> > >> >> >
> > >> >> > An early set of clang/llvm patches is needed to provide options
> to
> > >> >> > enable ThinLTO (off by default), so that the rest of the
> > >> >> > implementation can be disabled by default as it is added.
> > >> >> > Specifically, clang options -fthinlto (used instead of -flto)
> will
> > >> >> > cause clang to invoke the phase-1 emission of LLVM bitcode and
> > >> >> > function summary/index on a compile step, and pass the
> appropriate
> > >> >> > option to the gold plugin on a link step. The -thinlto option
> will
> > be
> > >> >> > added to the gold plugin and llvm-lto tool to launch the phase-2
> > thin
> > >> >> > archive step. The -thinlto option will also be added to the ?opt?
> > >> >> > tool
> > >> >> > to invoke it as a phase-3 parallel backend instance.
> > >> >> >
> > >> >> >
> > >> >> > b. Thin-archive linking support in Gold plugin and llvm-lto:
> > >> >> >
> > >> >> > Under the new plugin option (see above), the plugin needs to
> > perform
> > >> >> > the phase-2 (thin archive) link which simply emits a combined
> > >> >> > function
> > >> >> > map from the linked modules, without actually performing the
> normal
> > >> >> > link. Corresponding support should be added to the standalone
> > >> >> > llvm-lto
> > >> >> > tool to enable testing/debugging without involving the linker and
> > >> >> > plugin.
> > >> >> >
> > >> >> >
> > >> >> > c. ThinLTO backend support:
> > >> >> >
> > >> >> > Support for invoking a phase-3 backend invocation (including
> > >> >> > importing) on a module should be added to the ?opt? tool under
> the
> > >> >> > new
> > >> >> > option. The main change under the option is to instantiate a
> Linker
> > >> >> > object used to manage the process of linking imported functions
> > into
> > >> >> > the module, efficient read of the combined function map, and
> enable
> > >> >> > the ThinLTO import pass.
> > >> >> >
> > >> >> >
> > >> >> > d. Function index/summary support:
> > >> >> >
> > >> >> > This includes infrastructure for writing and reading the function
> > >> >> > index/summary section. As noted earlier this will be encoded in a
> > >> >> > special ELF section within the module, alongside the .llvmbc
> > section
> > >> >> > containing the bitcode. The thin archive generated by phase-2 of
> > >> >> > ThinLTO simply contains all of the function index/summary
> sections
> > >> >> > across the linked modules, organized for efficient function
> lookup.
> > >> >> >
> > >> >> > Each function available for importing from the module contains an
> > >> >> > entry in the module?s function index/summary section and in the
> > >> >> > resulting combined function map. Each function entry contains
> that
> > >> >> > function?s offset within the bitcode file, used to efficiently
> > locate
> > >> >> > and quickly import just that function. The entry also contains
> > >> >> > summary
> > >> >> > information (e.g. basic information determined during parsing
> such
> > as
> > >> >> > the number of instructions in the function), that will be used to
> > >> >> > help
> > >> >> > guide later import decisions. Because the contents of this
> section
> > >> >> > will change frequently during ThinLTO tuning, it should also be
> > >> >> > marked
> > >> >> > with a version id for backwards compatibility or version
> checking.
> > >> >> >
> > >> >> >
> > >> >> > e. ThinLTO importing support:
> > >> >> >
> > >> >> > Support for the mechanics of importing functions from other
> > modules,
> > >> >> > which can go in gradually as a set of patches since it will be
> off
> > by
> > >> >> > default. Separate patches can include:
> > >> >> >
> > >> >> > - BitcodeReader changes to use function index to
> import/deserialize
> > >> >> > single function of interest (small changes, leverages existing
> lazy
> > >> >> > streamer support).
> > >> >> >
> > >> >> > - Minor LTOModule changes to pass the ThinLTO function to import
> > and
> > >> >> > its index into bitcode reader.
> > >> >> >
> > >> >> > - Marking of imported functions (for use in ThinLTO-specific
> symbol
> > >> >> > linking and global DCE, for example). This can be in-memory
> > >> >> > initially,
> > >> >> > but IR support may be required in order to support streaming
> > bitcode
> > >> >> > out and back in again after importing.
> > >> >> >
> > >> >> > - ModuleLinker changes to do ThinLTO-specific symbol linking and
> > >> >> > static promotion when necessary. The linkage type of imported
> > >> >> > functions changes to AvailableExternallyLinkage, for example.
> > Statics
> > >> >> > must be promoted in certain cases, and renamed in consistent
> ways.
> > >> >> >
> > >> >> > - GlobalDCE changes to support removing imported functions that
> > were
> > >> >> > not inlined (very small changes to existing pass logic).
> > >> >> >
> > >> >> >
> > >> >> > f. ThinLTO Import Driver SCC pass:
> > >> >> >
> > >> >> > Adds Transforms/IPO/ThinLTO.cpp with framework for doing ThinLTO
> > via
> > >> >> > an SCC pass, enabled only under -fthinlto options. The pass
> > includes
> > >> >> > utilizing the thin archive (global function index/summary),
> import
> > >> >> > decision heuristics, invocation of LTOModule/ModuleLinker
> routines
> > >> >> > that perform the import, and any necessary callgraph updates and
> > >> >> > verification.
> > >> >> >
> > >> >> >
> > >> >> > g. Backend Driver:
> > >> >> >
> > >> >> > For a single node build, the gold plugin can simply write a
> > makefile
> > >> >> > and fork the parallel backend instances directly via parallel
> make.
> > >> >> >
> > >> >> >
> > >> >> > 3. Stage 3: ThinLTO Tuning and Enhancements
> > >> >> > ----------------------------------------------------------------
> > >> >> >
> > >> >> > This refers to the patches that are not required for ThinLTO to
> > work,
> > >> >> > but rather to improve compile time, memory, run-time performance
> > and
> > >> >> > usability.
> > >> >> >
> > >> >> >
> > >> >> > a. Lazy Debug Metadata Linking:
> > >> >> >
> > >> >> > The prototype implementation included lazy importing of
> > module-level
> > >> >> > metadata during the ThinLTO pass finalization (i.e. after all
> > >> >> > function
> > >> >> > importing is complete). This actually applies to all module-level
> > >> >> > metadata, not just debug, although it is the largest. This can be
> > >> >> > added as a separate set of patches. Changes to BitcodeReader,
> > >> >> > ValueMapper, ModuleLinker
> > >> >> >
> > >> >> >
> > >> >> > b. Import Tuning:
> > >> >> >
> > >> >> > Tuning the import strategy will be an iterative process that will
> > >> >> > continue to be refined over time. It involves several different
> > types
> > >> >> > of changes: adding support for recording additional metrics in
> the
> > >> >> > function summary, such as profile data and optional
> heavier-weight
> > >> >> > IPA
> > >> >> > analyses, and tuning the import heuristics based on the summary
> and
> > >> >> > callsite context.
> > >> >> >
> > >> >> >
> > >> >> > c. Combined Function Map Pruning:
> > >> >> >
> > >> >> > The combined function map can be pruned of functions that are
> > >> >> > unlikely
> > >> >> > to benefit from being imported. For example, during the phase-2
> > thin
> > >> >> > archive plug step we can safely omit large and (with profile
> data)
> > >> >> > cold functions, which are unlikely to benefit from being inlined.
> > >> >> > Additionally, all but one copy of comdat functions can be
> > suppressed.
> > >> >> >
> > >> >> >
> > >> >> > d. Distributed Build System Integration:
> > >> >> >
> > >> >> > For a distributed build system, the gold plugin should write the
> > >> >> > parallel backend invocations into a makefile, including the
> mapping
> > >> >> > from the IR file to the real object file path, and exit.
> Additional
> > >> >> > work needs to be done in the distributed build system itself to
> > >> >> > distribute and dispatch the parallel backend jobs to the build
> > >> >> > cluster.
> > >> >> >
> > >> >> >
> > >> >> > e. Dependence Tracking and Incremental Compiles:
> > >> >> >
> > >> >> > In order to support build systems that stage from local disks or
> > >> >> > network storage, the plugin will optionally support computation
> of
> > >> >> > dependent sets of IR files that each module may import from. This
> > can
> > >> >> > be computed from profile data, if it exists, or from the symbol
> > table
> > >> >> > and heuristics if not. These dependence sets also enable support
> > for
> > >> >> > incremental backend compiles.
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> > --
> > >> >> > Teresa Johnson | Software Engineer | tejohnson at google.com |
> > >> >> > 408-460-2413
> > >> >> >
> > >> >> > _______________________________________________
> > >> >> > 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
> > >> >
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> Teresa Johnson | Software Engineer | tejohnson at google.com |
> > 408-460-2413
> > >>
> > >> _______________________________________________
> > >> LLVM Developers mailing list
> > >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> > >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
> >
> >
> > --
> > Teresa Johnson | Software Engineer | tejohnson at google.com | 408-460-2413
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20150514/a29d04f5/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> LLVMdev mailing list
> LLVMdev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> End of LLVMdev Digest, Vol 131, Issue 56
> ****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150515/dd7ed5e2/attachment.html>
More information about the llvm-dev
mailing list