similar to: [LLVMdev] [llvm-commits] [patch] "TargetTransform" as an API between codegen and IR-level passes

Hi Renato, I think that we need to improve ::isTruncateFree, ::isZextFree, etc to include all of the free conversions. Vector and Scalar. Non-free conversions are marked with setOperationAction so the generic parts of TTI should be able to give a reasonable cost estimation. The cost tables should contain cases that are not handled by TTI. So, if we have a clever DAGCombine optimization (that

Hi all, I'm looking for a place where to put the costs of vector (and scalar) cast operations for ARM, but I noticed the TargetTransform methods call the TargetLowering ones when unsure. Now, I'm not sure... Many casts on ARM are free, and I could build a list of cases where it is true, but should I put this on the lowering or the transform? My main motivation is to get the costs right

On 25 January 2013 17:48, Nadav Rotem <nrotem at apple.com> wrote: > I think that we need to improve ::isTruncateFree, ::isZextFree, etc to > include all of the free conversions. Vector and Scalar. > Hi Nadav, Yes, and the question is: TargetLowering's isZExtFree or TargetTransform's isZExtFree? TargetTransform (TT) only has the free checks on types, while TargetLowering

> > TargetTransform (TT) only has the free checks on types, while TargetLowering (TL) has on SDValue and destination type. > Yes. This is a limitation of the current API. The design decision behind it was that in many cases you want to know the cost of IR before you generate it. For example, during vectorization you want to know how a particular IR would look if you were to vectorize

On 25 January 2013 23:03, Nadav Rotem <nrotem at apple.com> wrote: > Yes. This is a limitation of the current API. The design decision behind > it was that in many cases you want to know the cost of IR before you > generate it. > That makes sense. Also, we wanted to rely on tables as much as possible. We did not want to > write code to resemble ISel in order to estimate

Hi Hal, On 21/11/2012 22:38, Hal Finkel wrote: > ----- Original Message ----- >> From: "Ivan Llopard" <ivanllopard at gmail.com> >> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> >> Sent: Wednesday, November 21, 2012 10:31:07 AM >> Subject: [LLVMdev] Disable loop unroll pass >> >> Hi, >> >> We've a

Hi, We've a target which has hardware support for zero-overhead loops. Currently, we cannot detect them because the loop unroller is unrolling them before entering into the codegen. Looking at its implementation, it seems that it checks if it is profitable to unroll it or not based on certain parameters. Given that zero cost loops building is based more or less on the same constraints

----- Original Message ----- > From: "Ivan Llopard" <ivanllopard at gmail.com> > To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Wednesday, November 21, 2012 10:31:07 AM > Subject: [LLVMdev] Disable loop unroll pass > > Hi, > > We've a target which has hardware support for zero-overhead loops. > Currently, we

Hi, Ivan: My $0.02. hasZeroCostLooping() disabling unrolling dose not seem to be appropriate for other architectures, at least the one I worked before. You mentioned: >Currently, we cannot detect them because the loop unroller is >unrolling them before entering into the codegen. Looking at its implementation, >it. Could you please articulate why CG fail to recognize it?

Hi Shuxin, Eli, On 22/11/2012 03:19, Shuxin Yang wrote: > Hi, Ivan: > > My $0.02. hasZeroCostLooping() disabling unrolling dose not seem > to be > appropriate for other architectures, at least the one I worked before. I appreciate your feed-back. Could you give an example where building a hw loop is not appropriate for your target? > > You mentioned: >

I remember this being discussed, and may have even supported it, but I'm looking at cleaning up some of how the target transform info works, and it would be a lot less duplicate boiler-plate code to only have one. Having a narrower interface doesn't seem to make a lot of sense in this case because for the users, there is no real cost, and for the implementors, they always have to

Dear Duncan, thank you very much. I have been able to use it now, via the following command line: clang -emit-llvm -c -fstack-protector canary.c -o canary.bc llc -print-before=stack-protector -print-after=stack-protector -o canary.s < canary.bc Thank you again, Izabela Maffra. On 26 January 2013 15:55, <llvmdev-request at cs.uiuc.edu> wrote: > Send LLVMdev mailing

I am the designer for open64 hwloop structure, but I am not a student. Hope the following helps: To transform a loop into hwloop, we need the help from optimizer. For example, while(k3>=10){ sum+=k1; k3 --; } into the form: zdl_loop(k3-9) { sum+=k1; } So, we introduce a new ZDLBR whirl(open64 optimizer intermediate) operator, which represents the loop in whirl as: