llvm dev - Mar 2013 - [LLVMdev] Problems about developing LLVM pass on windows visual studio

I just want to know ,how can I developing a LLVM Pass  on Windows' visual
studio?
I can develop a Pass on linux,but I can't do it on windows.

2013/3/15 <llvmdev-request at cs.uiuc.edu>
> 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. Hexagon: removing support for Hexagon-v2 and Hexagon-v3
>       (Anshuman Dasgupta)
>    2. Re: Hexagon: removing support for Hexagon-v2 and  Hexagon-v3
>       (reed kotler)
>    3. Re: Suggestion About Adding Target Dependent Decision in  LSR
>       Please (Yin Ma)
>    4. Re: Suggestion About Adding Target Dependent Decision     in      LSR
>       Please (Hal Finkel)
>    5. Re: undefined reference to 'llvm_gcda_start_file',
>       'llvm_gcda_emit_arcs', etc (Qun Fa)
>    6. Re: Suggestion About Adding Target Dependent Decision     in      LSR
>       Please (Yin Ma)
>    7. Problems about developing LLVM pass on windows visual     studio
>       (tianxiang sui)
>    8. Re: Problems about developing LLVM pass on windows visual
>       studio (tianxiang sui)
>    9. Re: Get underlying object for Machine level memory        operation
>       (Rahul)
>   10. Re: undefined reference to 'llvm_gcda_start_file',
>       'llvm_gcda_emit_arcs', etc (Alexey Samsonov)
>   11. Can  the FileCheck  ignore spaces ? (Shawn)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 14 Mar 2013 14:51:52 -0500
> From: Anshuman Dasgupta <adasgupt at codeaurora.org>
> To: LLVM Dev <llvmdev at cs.uiuc.edu>
> Subject: [LLVMdev] Hexagon: removing support for Hexagon-v2 and
>         Hexagon-v3
> Message-ID: <51422A58.4080208 at codeaurora.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> I wanted to give everybody a heads-up on upcoming commits for the
> Hexagon backend. We will be removing support for older versions of the
> Hexagon architecture - specifically Hexagon-v2 and Hexagon-v3. These are
> no longer being used by compiler users. Matthew Curtis has committed the
> first clang patch to remove driver support for these versions. There
> will be follow-up patches on the LLVM side to remove instructions that
> are not used by newer versions of the architecture. After these changes,
> the compiler will support Hexagon-v4 and Hexagon-v5.
>
> Matthew has committed a short blurb in the 3.3 release notes. We'll add
> the reasons behind the removal to that note.
>
> Thanks
> -Anshu
>
> ---
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 14 Mar 2013 13:01:42 -0700
> From: reed kotler <rkotler at mips.com>
> To: "LLVMdev at cs.uiuc.edu" <LLVMdev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] Hexagon: removing support for Hexagon-v2 and
>         Hexagon-v3
> Message-ID: <51422CA6.20509 at mips.com>
> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
>
> On 03/14/2013 12:51 PM, Anshuman Dasgupta wrote:
> > I wanted to give everybody a heads-up on upcoming commits for the
> > Hexagon backend. We will be removing support for older versions of the
> > Hexagon architecture - specifically Hexagon-v2 and Hexagon-v3. These
are
> > no longer being used by compiler users. Matthew Curtis has committed
the
> > first clang patch to remove driver support for these versions. There
> > will be follow-up patches on the LLVM side to remove instructions that
> > are not used by newer versions of the architecture. After these
changes,
> > the compiler will support Hexagon-v4 and Hexagon-v5.
> >
> > Matthew has committed a short blurb in the 3.3 release notes.
We'll add
> > the reasons behind the removal to that note.
> >
> > Thanks
> > -Anshu
> >
> > ---
> > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> > hosted by The Linux Foundation
>
> There are no customers of yours that use Hexagon-V2 or Hexagon-V3 ??
>
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 14 Mar 2013 14:21:50 -0700
> From: "Yin Ma" <yinma at codeaurora.org>
> To: "'Andrew Trick'" <atrick at apple.com>
> Cc: llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] Suggestion About Adding Target Dependent
>         Decision in     LSR Please
> Message-ID: <0d7f01ce20f9$f1530b20$d3f92160$@codeaurora.org>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi Andy,
>
>
>
> Actually, if we just add hooks that preserves the existing behavior,
>
> It is not difficult. For example,
>
>
>
> For case one, we can define one function like
>
>   virtual const SCEV* getTargetPreferredWinnerReg(const SCEV*&
ScaledReg,
>
>            SmallVector<const SCEV *, 4>& BaseRegs,
GlobalValue*& BaseGV)
> const;
>
>
>
> In NarrowSearchSpaceByPickingWinnerRegs, we can preserves the winner
>
> reg from target and winner reg from the original algorithm if this function
>
> returns NULL, it is just like before
>
>
>
> For case two, we can define a general cost from TTI function, like
>
>   virtual int getLSRFormulaCost(const unsigned NumRegs,
>
>                             const unsigned AddRecCost, const unsigned
> NumIVMuls,
>
>                             const unsigned NumBaseAdds, const unsigned
> ImmCost,
>
>                             const unsigned SetupCost) const;
>
> Then we do something like
>
>   int thisCost = TTI->getLSRFormulaCost(NumRegs, AddRecCost, NumIVMuls,
>
>                                            NumBaseAdds, ImmCost,
> SetupCost);
>
>   if (thisCost >= 0) {
>
>     int otherCost = TTI->getLSRFormulaCost(Other.NumRegs,
Other.AddRecCost,
>
>                                             Other.NumIVMuls,
> Other.NumBaseAdds,
>
>                                             Other.ImmCost,
> Other.SetupCost);
>
>     if (otherCost >= 0)
>
>       return thisCost < otherCost;
>
>   }
>
> In bool Cost::operator<(const Cost &Other) const
>
>
>
> We could have more decision from target backend.
>
>
>
> However, from the problem I am dealing with, which has a lot of branches in
> multiple level
>
> Loop nests. LSR is still not able to perform the best because
>
> 1.       LSR is not control flow sensitive. It treats all USE equally,
> which
> doesn't care which
>
> USE is on critical path and which USE is on a branch. Without these kind of
> information,
>
> We cannot predict AddRec precisely because we only can assume all USEs can
> be post
>
> Increment or all not.
>
> 2.       The most occurred winner regs pruning may not be the best
> approach.
> Because target
>
> may prefer certain regs than others, even some registers do occur more.
> Specially,
>
> register with small computation is more likely to occur in formulas.
> However, register
>
> with small computation may not always be a best choice if the content in
> register are
>
> loop invariant.
>
>
>
> Therefore,  We may need a systemic agreement or plan to address the
> existing
> LSR problems. I
>
> would like to ask if any party has any improvement plan about LSR? So we
> can
> come together
>
> to have an unified solution to handle all known problem in one round?
>
>
>
> Thanks,
>
>
>
> Yin
>
>
>
>
>
> From: Andrew Trick [mailto:atrick at apple.com]
> Sent: Thursday, March 14, 2013 9:42 AM
> To: Yin Ma
> Cc: llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] Suggestion About Adding Target Dependent Decision in
> LSR Please
>
>
>
>
>
> On Mar 13, 2013, at 4:37 PM, Yin Ma <yinma at codeaurora.org> wrote:
>
>
>
>
>
> Hi All,
>
>
>
> In the target I am working, we comes cross a situation that the loop
> strength reduction
>
> could deliver a better result but currently not, because
>
> 1.       the algorithm narrows search space by winner registers without
> considering
>
> the target preferred format. (NarrowSearchSpaceByPickingWinnerRegs)
>
> 2.       Cost comparison solely favors the number register without
> considering other
>
> Impacts.
>
>
>
> For the case one,
>
> NarrowSearchSpaceByPickingWinnerRegs filters by most occurred registers.
>
> ld(basereg, immediate) is a target preferred addressing mode. However, it
> may
>
> be deleted because basereg is very likely not to be the most occurred
> register
>
> because the less opportunity in a combination.
>
>
>
> For the case two, by observing the cost comparison equation
>
> bool Cost::operator<(const Cost &Other) const {
>
>   if (NumRegs != Other.NumRegs)                            return NumRegs
<
> Other.NumRegs;
>
>   if (AddRecCost != Other.AddRecCost)                  return AddRecCost
<
> Other.AddRecCost;
>
>   if (NumIVMuls != Other.NumIVMuls)                   return NumIVMuls <
> Other.NumIVMuls;
>
>   if (NumBaseAdds != Other.NumBaseAdds)       return NumBaseAdds <
> Other.NumBaseAdds;
>
>   if (ImmCost != Other.ImmCost)                               return
> ImmCost
> < Other.ImmCost;
>
>   if (SetupCost != Other.SetupCost)                         return
> SetupCost
> < Other.SetupCost;
>
>   return false;
>
> }
>
>
>
> If we have a case to compare
>
> Cost at 5 regs, with addrec cost 1, plus 15 base adds, plus 1 imm cost,
> plus
> 4 setup cost.
>
> Cost at 4 regs, with addrec cost 1, plus 28 base adds, plus 1 imm cost,
> plus
> 2 setup cost.
>
> The current mode will select 4 regs case even there are 14 more base adds.
> And base
>
> Adds matters in our targets.
>
>
>
> So I think the current LSR should be pushing more decision into target
> dependent backend.
>
> Like calling new functions in TargetTransformInfo. At least, in narrow
> search space and cost
>
> comparison phase, or more in cost rating phase. LSR can be tightly cooped
> with the target
>
> attributes in order to get the most beneficial result.
>
>
>
> Yes. LSR decisions are tightly coupled with the target architecture and
> potentially the subtarget microarcthitecture. As you figured out, the way
> to
> handle it is to communicate more information to LSR through TTI. It's
easy
> to do this to solve individual benchmarks on your target. It's hard to
know
> if you have a general solution that works across targets. But if you can
> add
> hooks in a way that preserves existing behavior on other targets it
> shouldn't be a problem. We want to design general hooks, but leave it
up to
> someone doing the benchmarking to tune them for a particular target.
>
>
>
> -Andy
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
>
http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20130314/bce313bb/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 4
> Date: Thu, 14 Mar 2013 16:33:32 -0500 (CDT)
> From: Hal Finkel <hfinkel at anl.gov>
> To: Yin Ma <yinma at codeaurora.org>
> Cc: llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] Suggestion About Adding Target Dependent
>         Decision        in      LSR Please
> Message-ID:
>         <3249565.1962.1363296811077.JavaMail.javamailuser at
localhost>
> Content-Type: text/plain; charset=utf-8
>
> ----- Original Message -----
> > From: "Yin Ma" <yinma at codeaurora.org>
> > To: "Andrew Trick" <atrick at apple.com>
> > Cc: llvmdev at cs.uiuc.edu
> > Sent: Thursday, March 14, 2013 4:21:50 PM
> > Subject: Re: [LLVMdev] Suggestion About Adding Target Dependent
Decision
> in   LSR Please
> >
> >
> >
> >
> >
> > Hi Andy,
> >
> >
> >
> > Actually, if we just add hooks that preserves the existing behavior,
> >
> > It is not difficult. For example,
> >
> >
> >
> > For case one, we can define one function like
> >
> > virtual const SCEV* getTargetPreferredWinnerReg(const SCEV*&
> > ScaledReg,
> >
> > SmallVector<const SCEV *, 4>& BaseRegs, GlobalValue*&
BaseGV) const;
> >
> >
> >
> > In NarrowSearchSpaceByPickingWinnerRegs, we can preserves the winner
> >
> > reg from target and winner reg from the original algorithm if this
> > function
> >
> > returns NULL, it is just like before
> >
> >
> >
> > For case two, we can define a general cost from TTI function, like
> >
> > virtual int getLSRFormulaCost(const unsigned NumRegs,
> >
> > const unsigned AddRecCost, const unsigned NumIVMuls,
> >
> > const unsigned NumBaseAdds, const unsigned ImmCost,
> >
> > const unsigned SetupCost) const;
> >
> > Then we do something like
> >
> > int thisCost = TTI->getLSRFormulaCost(NumRegs, AddRecCost,
NumIVMuls,
> >
> > NumBaseAdds, ImmCost, SetupCost);
> >
> > if (thisCost >= 0) {
> >
> > int otherCost = TTI->getLSRFormulaCost(Other.NumRegs,
> > Other.AddRecCost,
> >
> > Other.NumIVMuls, Other.NumBaseAdds,
> >
> > Other.ImmCost, Other.SetupCost);
> >
> > if (otherCost >= 0)
> >
> > return thisCost < otherCost;
> >
> > }
> >
> > In bool Cost::operator<(const Cost &Other) const
> >
> >
> >
> > We could have more decision from target backend.
> >
> >
> >
> > However, from the problem I am dealing with, which has a lot of
> > branches in multiple level
> >
> > Loop nests. LSR is still not able to perform the best because
> >
> > 1. LSR is not control flow sensitive. It treats all USE equally,
> > which doesn?t care which
> >
> > USE is on critical path and which USE is on a branch. Without these
> > kind of information,
> >
> > We cannot predict AddRec precisely because we only can assume all
> > USEs can be post
> >
> > Increment or all not.
> >
> > 2. The most occurred winner regs pruning may not be the best
> > approach. Because target
> >
> > may prefer certain regs than others, even some registers do occur
> > more. Specially,
> >
> > register with small computation is more likely to occur in formulas.
> > However, register
> >
> > with small computation may not always be a best choice if the content
> > in register are
> >
> > loop invariant.
> >
> >
> >
> > Therefore, We may need a systemic agreement or plan to address the
> > existing LSR problems. I
> >
> > would like to ask if any party has any improvement plan about LSR? So
> > we can come together
> >
> > to have an unified solution to handle all known problem in one round?
>
> I am also planning to improve LSR to make it aware of pre-increment
> addressing. An underlying issue (as explained by Andy in the thread on
> "Pre-increment preparation pass" on the commits list) is that LSR
will not
> create pointer-valued PHIs when they don't already exist. I'd be
happy to
> work with you on this.
>
>  -Hal
>
> >
> >
> >
> > Thanks,
> >
> >
> >
> > Yin
> >
> >
> >
> >
> >
> >
> >
> > From: Andrew Trick [mailto:atrick at apple.com]
> > Sent: Thursday, March 14, 2013 9:42 AM
> > To: Yin Ma
> > Cc: llvmdev at cs.uiuc.edu
> > Subject: Re: [LLVMdev] Suggestion About Adding Target Dependent
> > Decision in LSR Please
> >
> >
> >
> >
> >
> >
> >
> > On Mar 13, 2013, at 4:37 PM, Yin Ma < yinma at codeaurora.org >
wrote:
> >
> >
> >
> >
> >
> >
> >
> > Hi All,
> >
> >
> >
> >
> >
> > In the target I am working, we comes cross a situation that the loop
> > strength reduction
> >
> >
> > could deliver a better result but currently not, because
> >
> >
> > 1. the algorithm narrows search space by winner registers without
> > considering
> >
> >
> > the target preferred format. (NarrowSearchSpaceByPickingWinnerRegs)
> >
> >
> > 2. Cost comparison solely favors the number register without
> > considering other
> >
> >
> > Impacts.
> >
> >
> >
> >
> >
> > For the case one,
> >
> >
> > NarrowSearchSpaceByPickingWinnerRegs filters by most occurred
> > registers.
> >
> >
> > ld(basereg, immediate) is a target preferred addressing mode.
> > However, it may
> >
> >
> > be deleted because basereg is very likely not to be the most occurred
> > register
> >
> >
> > because the less opportunity in a combination.
> >
> >
> >
> >
> >
> > For the case two, by observing the cost comparison equation
> >
> >
> > bool Cost::operator<(const Cost &Other) const {
> >
> >
> > if (NumRegs != Other.NumRegs) return NumRegs < Other.NumRegs;
> >
> >
> > if (AddRecCost != Other.AddRecCost) return AddRecCost <
> > Other.AddRecCost;
> >
> >
> > if (NumIVMuls != Other.NumIVMuls) return NumIVMuls <
Other.NumIVMuls;
> >
> >
> > if (NumBaseAdds != Other.NumBaseAdds) return NumBaseAdds <
> > Other.NumBaseAdds;
> >
> >
> > if (ImmCost != Other.ImmCost) return ImmCost < Other.ImmCost;
> >
> >
> > if (SetupCost != Other.SetupCost) return SetupCost <
Other.SetupCost;
> >
> >
> > return false;
> >
> >
> > }
> >
> >
> >
> >
> >
> > If we have a case to compare
> >
> >
> > Cost at 5 regs, with addrec cost 1, plus 15 base adds, plus 1 imm
> > cost, plus 4 setup cost.
> >
> >
> > Cost at 4 regs, with addrec cost 1, plus 28 base adds, plus 1 imm
> > cost, plus 2 setup cost.
> >
> >
> > The current mode will select 4 regs case even there are 14 more base
> > adds. And base
> >
> >
> > Adds matters in our targets.
> >
> >
> >
> >
> >
> > So I think the current LSR should be pushing more decision into
> > target dependent backend.
> >
> >
> > Like calling new functions in TargetTransformInfo. At least, in
> > narrow search space and cost
> >
> >
> > comparison phase, or more in cost rating phase. LSR can be tightly
> > cooped with the target
> >
> >
> > attributes in order to get the most beneficial result.
> >
> >
> >
> >
> > Yes. LSR decisions are tightly coupled with the target architecture
> > and potentially the subtarget microarcthitecture. As you figured
> > out, the way to handle it is to communicate more information to LSR
> > through TTI. It's easy to do this to solve individual benchmarks
on
> > your target. It's hard to know if you have a general solution that
> > works across targets. But if you can add hooks in a way that
> > preserves existing behavior on other targets it shouldn't be a
> > problem. We want to design general hooks, but leave it up to someone
> > doing the benchmarking to tune them for a particular target.
> >
> >
> >
> >
> >
> > -Andy
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
>
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 14 Mar 2013 16:36:49 -0500
> From: Qun Fa <testforqunfa at gmail.com>
> To: llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] undefined reference to
'llvm_gcda_start_file',
>         'llvm_gcda_emit_arcs', etc
> Message-ID:
>         <
> CADkYS3R1Hqo63TjvcoqT+q9MenpVdpTz-Go-88aE+6B0kQqePA at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi All,
>
> I think Nick's suggestion is correct, my code was linked against
> libprofile_rt.a, which had gcda profiling code before, but was removed
>
>
https://github.com/llvm-mirror/llvm/commit/218042a02305a3cc38d968a97ff9ecf4b4abe6ff
>
> So, I couldn't find the correct symbols from libprofile_rt.a any more.
>
> Now my assumption is I need to use the correct library that is provided by
> compiler-rt. May I know which one?
>
> I am building the entire llvm/clang including compiler-rt based on the
> instructions given on the clang get started page (
> http://clang.llvm.org/get_started.html), but with CMake instead of
> Makefile. But I also noticed in the compiler-rt/lib/CMakeLists.txt file, we
> have the following FIXME.
>
> # FIXME: Add support for the profile library.
>
> So, if I want to use the correct library, do I have to switch to Makefile?
> Any ideas?
>
> Thanks very much,
> Qun
>
>
>
> On Thu, Mar 14, 2013 at 8:46 AM, Qun Fa <testforqunfa at gmail.com>
wrote:
>
> > Thanks for your reply.
> >
> > May I know which is the recommended library that should be linked
> against?
> >
> > I am currently linking libprofile_rt.a.
> >
> > And I have noticed the differences that, if we do
> >
> > `nm libprofile_rt.a | grep llvm`
> >
> > with my old copy of the llvm/clang installation, I can see
> >
> > 00000000000005e0 T _llvm_gcda_emit_arcs
> > 0000000000000b48 S _llvm_gcda_emit_arcs.eh
> > 0000000000000430 T _llvm_gcda_emit_function
> > 0000000000000aa8 S _llvm_gcda_emit_function.eh
> > 00000000000006c0 T _llvm_gcda_end_file
> > 0000000000000b98 S _llvm_gcda_end_file.eh
> > 00000000000003d0 T _llvm_gcda_increment_indirect_counter
> > 0000000000000a80 S _llvm_gcda_increment_indirect_counter.eh
> > 0000000000000000 T _llvm_gcda_start_file
> > 0000000000000a08 S _llvm_gcda_start_file.eh
> >
> > They are the symbols that my test build is looking for.
> >
> > But with the latest codebase, here is what I saw
> >
> > 00000000000000a8 T llvm_start_basic_block_tracing
> > 0000000000000067 T llvm_trace_basic_block
> > 0000000000000467 T llvm_decrement_path_count
> > 000000000000042a T llvm_increment_path_count
> > 0000000000000662 T llvm_start_path_profiling
> > 0000000000000020 T llvm_start_edge_profiling
> > 0000000000000020 T llvm_start_opt_edge_profiling
> >
> > Thanks again,
> > Qun
> >
> > On Thu, Mar 14, 2013 at 1:11 AM, Nick Lewycky <nicholas at
mxc.ca> wrote:
> >
> >> Qun Fa wrote:
> >>
> >>> Hi,
> >>> I am trying to test my project and get the code coverage with
a version
> >>> of clang compiler that was built from the latest llvm/clang
codebase.
> >>>
> >>> It worked for a while. But today, after I updated my local
checkout,
> and
> >>> re-build llvm, clang and compiler-rt, when I test my project
again, I
> >>> got the errors with undefined reference to
'llvm_gcda_start_file',
> >>> 'llvm_gcda_emit_arcs',
'llvm_gcda_emit_function', and
> >>> 'llvm_gcda_end_file'.
> >>>
> >>> I have searched the codebase, and have found the functions are
defined
> >>> in GCDAProfiling.c file, but not sure why this suddenly
doesn't work
> for
> >>> me.
> >>>
> >>> Anyone can give any suggestions?
> >>>
> >>
> >> Those symbols should be provided by
> compiler-rt/lib/profile/**GCDAProfiling.c.
> >> There used to be a copy in llvm's tree, but I deleted that one
recently.
> >> It's possible you used to be using the one from llvm, but now
need to
> >> switch to using the one from compiler-rt?
> >>
> >> Nick
> >>
> >>
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
>
http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20130314/f5dd05bc/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 6
> Date: Thu, 14 Mar 2013 14:43:38 -0700
> From: "Yin Ma" <yinma at codeaurora.org>
> To: "'Hal Finkel'" <hfinkel at anl.gov>
> Cc: llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] Suggestion About Adding Target Dependent
>         Decision        in      LSR Please
> Message-ID: <0da401ce20fc$fc8d9e30$f5a8da90$@codeaurora.org>
> Content-Type: text/plain;       charset="UTF-8"
>
> Hi Hal,
>
> We are also facing the post increment problem. If a USE in a branch in a
> loop body,
> post increment mode may not be applicable. So to estimate the real number
> of AddRec,
> the current LSR need a little more Information to determine the mode.
>
>
> Yin
>
>
>
> -----Original Message-----
> From: Hal Finkel [mailto:hfinkel at anl.gov]
> Sent: Thursday, March 14, 2013 2:34 PM
> To: Yin Ma
> Cc: llvmdev at cs.uiuc.edu; Andrew Trick
> Subject: Re: [LLVMdev] Suggestion About Adding Target Dependent Decision
> in LSR Please
>
> ----- Original Message -----
> > From: "Yin Ma" <yinma at codeaurora.org>
> > To: "Andrew Trick" <atrick at apple.com>
> > Cc: llvmdev at cs.uiuc.edu
> > Sent: Thursday, March 14, 2013 4:21:50 PM
> > Subject: Re: [LLVMdev] Suggestion About Adding Target Dependent
Decision
> in   LSR Please
> >
> >
> >
> >
> >
> > Hi Andy,
> >
> >
> >
> > Actually, if we just add hooks that preserves the existing behavior,
> >
> > It is not difficult. For example,
> >
> >
> >
> > For case one, we can define one function like
> >
> > virtual const SCEV* getTargetPreferredWinnerReg(const SCEV*&
> > ScaledReg,
> >
> > SmallVector<const SCEV *, 4>& BaseRegs, GlobalValue*&
BaseGV) const;
> >
> >
> >
> > In NarrowSearchSpaceByPickingWinnerRegs, we can preserves the winner
> >
> > reg from target and winner reg from the original algorithm if this
> > function
> >
> > returns NULL, it is just like before
> >
> >
> >
> > For case two, we can define a general cost from TTI function, like
> >
> > virtual int getLSRFormulaCost(const unsigned NumRegs,
> >
> > const unsigned AddRecCost, const unsigned NumIVMuls,
> >
> > const unsigned NumBaseAdds, const unsigned ImmCost,
> >
> > const unsigned SetupCost) const;
> >
> > Then we do something like
> >
> > int thisCost = TTI->getLSRFormulaCost(NumRegs, AddRecCost,
NumIVMuls,
> >
> > NumBaseAdds, ImmCost, SetupCost);
> >
> > if (thisCost >= 0) {
> >
> > int otherCost = TTI->getLSRFormulaCost(Other.NumRegs,
> > Other.AddRecCost,
> >
> > Other.NumIVMuls, Other.NumBaseAdds,
> >
> > Other.ImmCost, Other.SetupCost);
> >
> > if (otherCost >= 0)
> >
> > return thisCost < otherCost;
> >
> > }
> >
> > In bool Cost::operator<(const Cost &Other) const
> >
> >
> >
> > We could have more decision from target backend.
> >
> >
> >
> > However, from the problem I am dealing with, which has a lot of
> > branches in multiple level
> >
> > Loop nests. LSR is still not able to perform the best because
> >
> > 1. LSR is not control flow sensitive. It treats all USE equally, which
> > doesn?t care which
> >
> > USE is on critical path and which USE is on a branch. Without these
> > kind of information,
> >
> > We cannot predict AddRec precisely because we only can assume all USEs
> > can be post
> >
> > Increment or all not.
> >
> > 2. The most occurred winner regs pruning may not be the best approach.
> > Because target
> >
> > may prefer certain regs than others, even some registers do occur
> > more. Specially,
> >
> > register with small computation is more likely to occur in formulas.
> > However, register
> >
> > with small computation may not always be a best choice if the content
> > in register are
> >
> > loop invariant.
> >
> >
> >
> > Therefore, We may need a systemic agreement or plan to address the
> > existing LSR problems. I
> >
> > would like to ask if any party has any improvement plan about LSR? So
> > we can come together
> >
> > to have an unified solution to handle all known problem in one round?
>
> I am also planning to improve LSR to make it aware of pre-increment
> addressing. An underlying issue (as explained by Andy in the thread on
> "Pre-increment preparation pass" on the commits list) is that LSR
will not
> create pointer-valued PHIs when they don't already exist. I'd be
happy to
> work with you on this.
>
>  -Hal
>
> >
> >
> >
> > Thanks,
> >
> >
> >
> > Yin
> >
> >
> >
> >
> >
> >
> >
> > From: Andrew Trick [mailto:atrick at apple.com]
> > Sent: Thursday, March 14, 2013 9:42 AM
> > To: Yin Ma
> > Cc: llvmdev at cs.uiuc.edu
> > Subject: Re: [LLVMdev] Suggestion About Adding Target Dependent
> > Decision in LSR Please
> >
> >
> >
> >
> >
> >
> >
> > On Mar 13, 2013, at 4:37 PM, Yin Ma < yinma at codeaurora.org >
wrote:
> >
> >
> >
> >
> >
> >
> >
> > Hi All,
> >
> >
> >
> >
> >
> > In the target I am working, we comes cross a situation that the loop
> > strength reduction
> >
> >
> > could deliver a better result but currently not, because
> >
> >
> > 1. the algorithm narrows search space by winner registers without
> > considering
> >
> >
> > the target preferred format. (NarrowSearchSpaceByPickingWinnerRegs)
> >
> >
> > 2. Cost comparison solely favors the number register without
> > considering other
> >
> >
> > Impacts.
> >
> >
> >
> >
> >
> > For the case one,
> >
> >
> > NarrowSearchSpaceByPickingWinnerRegs filters by most occurred
> > registers.
> >
> >
> > ld(basereg, immediate) is a target preferred addressing mode.
> > However, it may
> >
> >
> > be deleted because basereg is very likely not to be the most occurred
> > register
> >
> >
> > because the less opportunity in a combination.
> >
> >
> >
> >
> >
> > For the case two, by observing the cost comparison equation
> >
> >
> > bool Cost::operator<(const Cost &Other) const {
> >
> >
> > if (NumRegs != Other.NumRegs) return NumRegs < Other.NumRegs;
> >
> >
> > if (AddRecCost != Other.AddRecCost) return AddRecCost <
> > Other.AddRecCost;
> >
> >
> > if (NumIVMuls != Other.NumIVMuls) return NumIVMuls <
Other.NumIVMuls;
> >
> >
> > if (NumBaseAdds != Other.NumBaseAdds) return NumBaseAdds <
> > Other.NumBaseAdds;
> >
> >
> > if (ImmCost != Other.ImmCost) return ImmCost < Other.ImmCost;
> >
> >
> > if (SetupCost != Other.SetupCost) return SetupCost <
Other.SetupCost;
> >
> >
> > return false;
> >
> >
> > }
> >
> >
> >
> >
> >
> > If we have a case to compare
> >
> >
> > Cost at 5 regs, with addrec cost 1, plus 15 base adds, plus 1 imm
> > cost, plus 4 setup cost.
> >
> >
> > Cost at 4 regs, with addrec cost 1, plus 28 base adds, plus 1 imm
> > cost, plus 2 setup cost.
> >
> >
> > The current mode will select 4 regs case even there are 14 more base
> > adds. And base
> >
> >
> > Adds matters in our targets.
> >
> >
> >
> >
> >
> > So I think the current LSR should be pushing more decision into target
> > dependent backend.
> >
> >
> > Like calling new functions in TargetTransformInfo. At least, in narrow
> > search space and cost
> >
> >
> > comparison phase, or more in cost rating phase. LSR can be tightly
> > cooped with the target
> >
> >
> > attributes in order to get the most beneficial result.
> >
> >
> >
> >
> > Yes. LSR decisions are tightly coupled with the target architecture
> > and potentially the subtarget microarcthitecture. As you figured out,
> > the way to handle it is to communicate more information to LSR through
> > TTI. It's easy to do this to solve individual benchmarks on your
> > target. It's hard to know if you have a general solution that
works
> > across targets. But if you can add hooks in a way that preserves
> > existing behavior on other targets it shouldn't be a problem. We
want
> > to design general hooks, but leave it up to someone doing the
> > benchmarking to tune them for a particular target.
> >
> >
> >
> >
> >
> > -Andy
> > _______________________________________________
> > 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: Fri, 15 Mar 2013 10:51:50 +0800
> From: tianxiang sui <suitianxiang at gmail.com>
> To: llvmdev at cs.uiuc.edu
> Subject: [LLVMdev] Problems about developing LLVM pass on windows
>         visual  studio
> Message-ID:
>         <
> CAED3LxuNdm+aS7W_h9Ww17mNMZjRJWt6uoyeip+emcOgwQmf9w at mail.gmail.com>
> Content-Type: text/plain; charset="gb2312"
>
> hello?
> recently,I read the document about?getting started with the LLVM system
> using Microsoft Visual Studio ?.And
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
>
http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20130315/d4537b80/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 8
> Date: Fri, 15 Mar 2013 10:56:58 +0800
> From: tianxiang sui <suitianxiang at gmail.com>
> To: llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] Problems about developing LLVM pass on windows
>         visual  studio
> Message-ID:
>         <CAED3Lxukzx_C4BMtdqzjRJS0Q6M0R1PXjnwgyC> RfWoLs72ZGQ at
mail.gmail.com>
> Content-Type: text/plain; charset="gb2312"
>
> sorry,I just made a mistake.I do the work and test it with hello.c. Now I
> want to develop a LLVMPass,I don't know whether it can work in this
> environment.
> Eagerly awaiting your reply.
>
> 2013/3/15 tianxiang sui <suitianxiang at gmail.com>
>
> > hello?
> > recently,I read the document about?getting started with the LLVM
system
> > using Microsoft Visual Studio ?.And
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
>
http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20130315/1dc06576/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 9
> Date: Fri, 15 Mar 2013 09:19:22 +0530
> From: Rahul <rahul3527 at gmail.com>
> To: Nadav Rotem <nrotem at apple.com>
> Cc: Dev <llvmdev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] Get underlying object for Machine level memory
>         operation
> Message-ID:
>         <CAPTz28BWGjhhTu2wKMNNZPrbJaZZkORuwEieGNWSRSVqt> b6vQ at
mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi,
>
> Thanks for suggestion :)
> Since I am using llvm-3.1, I didn't find method
> "GetUnderlyingObjects "(available in llvm-3.2).
> I was writing my own function to handle various memory operands. But I
> guess, this should help me out.
>
> Thanks,
> Rahul
>
>
> On Thu, Mar 14, 2013 at 10:06 PM, Nadav Rotem <nrotem at apple.com>
wrote:
>
> > You can use the GetUnderlyingObjects function (notice the S at the end
of
> > the name) to collect zero or more underlying objects.  This method is
> > similar to GetUnderlyingObject except that it can look through phi and
> > select instructions and return multiple objects.
> >
> > On Mar 14, 2013, at 4:15 AM, rahul <rahul3527 at gmail.com>
wrote:
> >
> > Hi,
> >
> > I am writing a pass that works at machine level and runs as last pass
in
> > llc (just before converting llvm specific machine instructions into
> target
> > specific instructions)
> > In this pass I am trying to get underlying object for memory
operations.
> > It turns out that due to various optimizations on machine
instructions,
> > the memory operand in the operation is not always getelementptr (for
> e.g.,
> > it can be phi node/bitcast/inttoptr instruction)
> > Can someone suggest best way to get the underlying object??
> >
> > --
> > Regards,
> > Rahul Patil.
> >
> > ------------------------------
> > View this message in context: Get underlying object for Machine level
> > memory operation<
>
http://llvm.1065342.n5.nabble.com/Get-underlying-object-for-Machine-level-memory-operation-tp55970.html
> >
> > Sent from the LLVM - Dev mailing list archive<
> http://llvm.1065342.n5.nabble.com/LLVM-Dev-f3.html>
> >  at Nabble.com <http://nabble.com/>.
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
> >
> >
>
>
> --
> Regards,
> Rahul Patil.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
>
http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20130315/56dfa90f/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 10
> Date: Fri, 15 Mar 2013 10:51:03 +0400
> From: Alexey Samsonov <samsonov at google.com>
> To: Qun Fa <testforqunfa at gmail.com>
> Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] undefined reference to
'llvm_gcda_start_file',
>         'llvm_gcda_emit_arcs', etc
> Message-ID:
>         <
> CAGSYnCPw+RPC_ze6ZsHhTdgcdFkisJpT_gYdJbk+ingEeLgZVw at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Fri, Mar 15, 2013 at 1:36 AM, Qun Fa <testforqunfa at gmail.com>
wrote:
>
> > Hi All,
> >
> > I think Nick's suggestion is correct, my code was linked against
> > libprofile_rt.a, which had gcda profiling code before, but was removed
> >
>
https://github.com/llvm-mirror/llvm/commit/218042a02305a3cc38d968a97ff9ecf4b4abe6ff
> >
> > So, I couldn't find the correct symbols from libprofile_rt.a any
more.
> >
> > Now my assumption is I need to use the correct library that is
provided
> by
> > compiler-rt. May I know which one?
> >
> > I am building the entire llvm/clang including compiler-rt based on the
> > instructions given on the clang get started page (
> > http://clang.llvm.org/get_started.html), but with CMake instead of
> > Makefile. But I also noticed in the compiler-rt/lib/CMakeLists.txt
file,
> we
> > have the following FIXME.
> >
> > # FIXME: Add support for the profile library.
> >
> > So, if I want to use the correct library, do I have to switch to
> Makefile?
> > Any ideas?
> >
>
> Yeah, can you try Makefile (I think it should build libprofile_rt from
> GCDAProfiling.c that you need). I'll see if I can add CMake support for
> profile in compiler-rt any time soon.
> However, looks like Clang driver won't be smart enough to link two
archives
> (lib/libprofile_rt.a and the one under lib/clang/3.3/linux/...), so we may
> need to patch the driver as well.
>
>
> >
> > Thanks very much,
> > Qun
> >
> >
> >
> > On Thu, Mar 14, 2013 at 8:46 AM, Qun Fa <testforqunfa at
gmail.com> wrote:
> >
> >> Thanks for your reply.
> >>
> >> May I know which is the recommended library that should be linked
> against?
> >>
> >> I am currently linking libprofile_rt.a.
> >>
> >> And I have noticed the differences that, if we do
> >>
> >> `nm libprofile_rt.a | grep llvm`
> >>
> >> with my old copy of the llvm/clang installation, I can see
> >>
> >> 00000000000005e0 T _llvm_gcda_emit_arcs
> >> 0000000000000b48 S _llvm_gcda_emit_arcs.eh
> >> 0000000000000430 T _llvm_gcda_emit_function
> >> 0000000000000aa8 S _llvm_gcda_emit_function.eh
> >> 00000000000006c0 T _llvm_gcda_end_file
> >> 0000000000000b98 S _llvm_gcda_end_file.eh
> >> 00000000000003d0 T _llvm_gcda_increment_indirect_counter
> >> 0000000000000a80 S _llvm_gcda_increment_indirect_counter.eh
> >> 0000000000000000 T _llvm_gcda_start_file
> >> 0000000000000a08 S _llvm_gcda_start_file.eh
> >>
> >> They are the symbols that my test build is looking for.
> >>
> >> But with the latest codebase, here is what I saw
> >>
> >> 00000000000000a8 T llvm_start_basic_block_tracing
> >> 0000000000000067 T llvm_trace_basic_block
> >> 0000000000000467 T llvm_decrement_path_count
> >> 000000000000042a T llvm_increment_path_count
> >> 0000000000000662 T llvm_start_path_profiling
> >> 0000000000000020 T llvm_start_edge_profiling
> >> 0000000000000020 T llvm_start_opt_edge_profiling
> >>
> >> Thanks again,
> >> Qun
> >>
> >> On Thu, Mar 14, 2013 at 1:11 AM, Nick Lewycky <nicholas at
mxc.ca> wrote:
> >>
> >>> Qun Fa wrote:
> >>>
> >>>> Hi,
> >>>> I am trying to test my project and get the code coverage
with a
> version
> >>>> of clang compiler that was built from the latest
llvm/clang codebase.
> >>>>
> >>>> It worked for a while. But today, after I updated my local
checkout,
> and
> >>>> re-build llvm, clang and compiler-rt, when I test my
project again, I
> >>>> got the errors with undefined reference to
'llvm_gcda_start_file',
> >>>> 'llvm_gcda_emit_arcs',
'llvm_gcda_emit_function', and
> >>>> 'llvm_gcda_end_file'.
> >>>>
> >>>> I have searched the codebase, and have found the functions
are defined
> >>>> in GCDAProfiling.c file, but not sure why this suddenly
doesn't work
> >>>> for me.
> >>>>
> >>>> Anyone can give any suggestions?
> >>>>
> >>>
> >>> Those symbols should be provided by
> compiler-rt/lib/profile/**GCDAProfiling.c.
> >>> There used to be a copy in llvm's tree, but I deleted that
one
> recently.
> >>> It's possible you used to be using the one from llvm, but
now need to
> >>> switch to using the one from compiler-rt?
> >>>
> >>> Nick
> >>>
> >>>
> >>
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
> >
>
>
> --
> Alexey Samsonov, MSK
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
>
http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20130315/8e9db450/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 11
> Date: Fri, 15 Mar 2013 16:16:00 +0800
> From: Shawn <shaolin.xie at ia.ac.cn>
> To: llvmdev at cs.uiuc.edu
> Cc: Zhang Yu <clarazhang at gmail.com>
> Subject: [LLVMdev] Can  the FileCheck  ignore spaces ?
> Message-ID: <5142D8C0.6060407 at ia.ac.cn>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi all:
>      I'm writing testcase for the MC layer regression  in llvm, the
> disassembled string is a bit complicate, for example:
>      "IALU.T0 (I0) = BIU0.DM ; REPEAT AT ( 2 ) ;;"
>      The spaces in the disassembled string is error-prone. Is there any
> option to tell the FileCheck utility to ignore the spaces ?
>
>       Kind Regards.
>
> Shawn.
>
>
>
> ------------------------------
>
> _______________________________________________
> LLVMdev mailing list
> LLVMdev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> End of LLVMdev Digest, Vol 105, Issue 30
> ****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130315/3703b760/attachment.html>