Thanks a lot for the reply, Nadav! I see that using the cost model in target-independent analysis is not good. But I really like the idea of having instruction cost estimation available. Also the reason I can't directly move to 3.2 code base is that it fails to compile(produce bc files) big project like MySQL, where 3.0 has no problem. Right now, I'm trying to hard code a particular target, and copy part of the TargetTransformInfo and X86TargetTransformInfo to a simple LLVM 3.0 project to try out. So far I'm stuck in instantiating X86TargetMachine and wondering whether it can be created from instances of TargetMachine or TargetData. Thank you! Best Regards, Ryan On Thu, Feb 7, 2013 at 10:45 AM, Nadav Rotem <nrotem at apple.com> wrote:> Hi Ryan, > > I think that it would be difficult to back port the CostModel back to > LLVM3.0 because it uses the new TargetTransformInfo analysis. I also > wanted to mention that only _lowering_ passes (target-specific optimization > passes) may use TTI and the cost model. Higher-level canonicalization > passes should not use it. > > Thanks, > Nadav > > On Feb 6, 2013, at 1:26 AM, ryan <stdstack at gmail.com> wrote: > > > Hi All, > > I wanted to do some basic cost estimation of Instruction/BB. There're > CostModelAnalysis and CodeMetrics available in 3.1 and 3.2 releases. > > I've been using 3.0 for a while. I'm wondering whether similar analysis > can be done in the old 3.0 release, e.g. back porting the implementation. > > > > Thank you! > > > > Best, > > Ryan > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130207/9fe64f44/attachment.html>
On Feb 7, 2013, at 3:17 PM, ryan <stdstack at gmail.com> wrote:> Thanks a lot for the reply, Nadav! > I see that using the cost model in target-independent analysis is not good. But I really like the idea of having instruction > cost estimation available. Also the reason I can't directly move to 3.2 code base is that it fails to compile(produce bc files) big > project like MySQL, where 3.0 has no problem. >Is this a known problem ? Can you please file a bugzilla ? LLVM should be able to compiler MySQL …> Right now, I'm trying to hard code a particular target, and copy part of the TargetTransformInfo and X86TargetTransformInfo > to a simple LLVM 3.0 project to try out. So far I'm stuck in instantiating X86TargetMachine and wondering whether it can be > created from instances of TargetMachine or TargetData. >Look at tools/opt/opt.cpp or tools/llc/llc.cpp. They both initialize the target machine using the target data.
On Thu, Feb 7, 2013 at 3:23 PM, Nadav Rotem <nrotem at apple.com> wrote:> > On Feb 7, 2013, at 3:17 PM, ryan <stdstack at gmail.com> wrote: > > > Thanks a lot for the reply, Nadav! > > I see that using the cost model in target-independent analysis is not > good. But I really like the idea of having instruction > > cost estimation available. Also the reason I can't directly move to 3.2 > code base is that it fails to compile(produce bc files) big > > project like MySQL, where 3.0 has no problem. > > > > Is this a known problem ? Can you please file a bugzilla ? LLVM should be > able to compiler MySQL … > > OK. I didn't find much on the internet related to theclang compilation error. Just filed the bug report http://llvm.org/bugs/show_bug.cgi?id=15206> > > Right now, I'm trying to hard code a particular target, and copy part of > the TargetTransformInfo and X86TargetTransformInfo > > to a simple LLVM 3.0 project to try out. So far I'm stuck in > instantiating X86TargetMachine and wondering whether it can be > > created from instances of TargetMachine or TargetData. > > > > Look at tools/opt/opt.cpp or tools/llc/llc.cpp. They both initialize the > target machine using the target data. > > Thanks a lot for the pointer. I'll take a look!Best regards, Ryan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130207/6790b7f4/attachment.html>