[LLVMdev] Problems about developing LLVM pass on windows visual studio

[tianxiang sui]

hello：

recently,I read the document about“getting started with the LLVM system using Microsoft Visual Studio “.And

[tianxiang sui]

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 <suitia...@gmail.com>

[tianxiang sui]

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...@cs.uiuc.edu>

Send LLVMdev mailing list submissions to
        llv...@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...@cs.uiuc.edu

You can reach the person managing the list at
        llvmde...@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 <adas...@codeaurora.org>
To: LLVM Dev <llv...@cs.uiuc.edu>
Subject: [LLVMdev] Hexagon: removing support for Hexagon-v2 and
        Hexagon-v3
Message-ID: <51422A58...@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 <rko...@mips.com>
To: "LLV...@cs.uiuc.edu" <LLV...@cs.uiuc.edu>
Subject: Re: [LLVMdev] Hexagon: removing support for Hexagon-v2 and
        Hexagon-v3
Message-ID: <51422CA...@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" <yi...@codeaurora.org>
To: "'Andrew Trick'" <atr...@apple.com>
Cc: llv...@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:atr...@apple.com]
Sent: Thursday, March 14, 2013 9:42 AM
To: Yin Ma
Cc: llv...@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 <yi...@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 <hfi...@anl.gov>
To: Yin Ma <yi...@codeaurora.org>
Cc: llv...@cs.uiuc.edu
Subject: Re: [LLVMdev] Suggestion About Adding Target Dependent
        Decision        in      LSR Please
Message-ID:
        <3249565.1962.1363296811077.JavaMail.javamailuser@localhost>
Content-Type: text/plain; charset=utf-8

----- Original Message -----
> From: "Yin Ma" <yi...@codeaurora.org>
> To: "Andrew Trick" <atr...@apple.com>
> Cc: llv...@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:atr...@apple.com]
> Sent: Thursday, March 14, 2013 9:42 AM
> To: Yin Ma
> Cc: llv...@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 < yi...@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
> LLV...@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 <testfo...@gmail.com>
To: llv...@cs.uiuc.edu
Subject: Re: [LLVMdev] undefined reference to 'llvm_gcda_start_file',
        'llvm_gcda_emit_arcs', etc
Message-ID:
        <CADkYS3R1Hqo63TjvcoqT+q9M...@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 <testfo...@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 <nich...@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" <yi...@codeaurora.org>
To: "'Hal Finkel'" <hfi...@anl.gov>
Cc: llv...@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:hfi...@anl.gov]
Sent: Thursday, March 14, 2013 2:34 PM
To: Yin Ma
Cc: llv...@cs.uiuc.edu; Andrew Trick
Subject: Re: [LLVMdev] Suggestion About Adding Target Dependent Decision in LSR Please

----- Original Message -----
> From: "Yin Ma" <yi...@codeaurora.org>
> To: "Andrew Trick" <atr...@apple.com>
> Cc: llv...@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:atr...@apple.com]
> Sent: Thursday, March 14, 2013 9:42 AM
> To: Yin Ma
> Cc: llv...@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 < yi...@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
> LLV...@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 <suitia...@gmail.com>
To: llv...@cs.uiuc.edu
Subject: [LLVMdev] Problems about developing LLVM pass on windows
        visual  studio
Message-ID:
        <CAED3LxuNdm+aS7W_h9Ww17mN...@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 <suitia...@gmail.com>
To: llv...@cs.uiuc.edu
Subject: Re: [LLVMdev] Problems about developing LLVM pass on windows
        visual  studio
Message-ID:
        <CAED3Lxukzx_C4BMtdqzjRJS0Q6M0R1PXjnwgyC=RfWoL...@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 <suitia...@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 <rahu...@gmail.com>
To: Nadav Rotem <nro...@apple.com>
Cc: Dev <llv...@cs.uiuc.edu>
Subject: Re: [LLVMdev] Get underlying object for Machine level memory
        operation
Message-ID:
        <CAPTz28BWGjhhTu2wKMNNZPrbJaZZkORuwEieGNWSRSVqt=b6...@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 <nro...@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 <rahu...@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
> LLV...@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 <sams...@google.com>
To: Qun Fa <testfo...@gmail.com>
Cc: LLVM Developers Mailing List <llv...@cs.uiuc.edu>
Subject: Re: [LLVMdev] undefined reference to 'llvm_gcda_start_file',
        'llvm_gcda_emit_arcs', etc
Message-ID:
        <CAGSYnCPw+RPC_ze6ZsHhTdgc...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

On Fri, Mar 15, 2013 at 1:36 AM, Qun Fa <testfo...@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 <testfo...@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 <nich...@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
> LLV...@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 <shaol...@ia.ac.cn>
To: llv...@cs.uiuc.edu
Cc: Zhang Yu <clara...@gmail.com>
Subject: [LLVMdev] Can  the FileCheck  ignore spaces ?
Message-ID: <5142D8C0...@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
LLV...@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


End of LLVMdev Digest, Vol 105, Issue 30
****************************************