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