similar to: [LLVMdev] TargetLowering vs. TargetTransform

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

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

The functions that I placed in ScalarTargetTransformInfo are functions what were used by LSR and LowerInvoke. getJumpSize and getJumpAlignment are used by LowerInvoke. Do you suggest that I remove them from TargetLowering and keep them in ScalarTargetTransformInfo ? Thanks, Nadav On Oct 9, 2012, at 5:47 PM, Evan Cheng <evan.cheng at apple.com> wrote: > Hi Nadav, > > The

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 all, I have been looking at the way LLVM optimizes code before forwarding it to the backend I develop for my company and while building define i32 @test_extract_subreg_func(i32 %x, i32 %y) #0 { entry: %conv = zext i32 %x to i64 %conv1 = zext i32 %y to i64 %mul = mul nuw i64 %conv1, %conv %shr = lshr i64 %mul, 32 %xor = xor i64 %shr, %mul %conv2 = trunc i64 %xor to i32

Hi, I noticed many functions in the TargetTransformInfo interface are duplicates of those already in TargetLowering (e.g. isTruncateFree). Is the expectation really that targets will reimplement the same functions twice? AArch64’s TTI uses some TLI calls in some of its implementations, but why doesn’t the base TargetTransformInfo call the TargetLowering versions by default? - Matt

Hi Nadav, I'm interested in knowing how you'll work up the ARM cost model and how easy it'd be to split the work. As far as I can see, LoopVectorizationCostModel is the class that does all the work, with assistance from the target transform info. Do you think that updating ARMTTI would be the best course of action now, and inspect the differences in the CostModel later? I also

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

Hi Renato, > I'm interested in knowing how you'll work up the ARM cost model and how easy it'd be to split the work. Yes, I am starting to work on the ARM cost model and I would appreciate any help in the form of: advice, performance measurements, patches, etc. I tune the cost model by running the cost model analysis pass and I compare the output of the analysis to the output

Hi, Within a basic block I can remove unnecessary register copies + zero sign extensions of unsigned-8bit-loaded values by implementing isZExtFree() for ISD::LOAD nodes. ...But not between basic blocks. The first block does a CopyFromReg of the unsigned-8bit-loaded vreg1 into a new vreg2. The second block then does a unnecessary zext to vreg2. What I want is the 2nd block to use the original

Hi, I see that for different targets in classes which inherits from TargetLowering there are implemented both methods: LowerOperation and ReplaceNodeResults What decides that for one given ISD we have to add handling in LowerOperation and for other in ReplaceNodeResults, when for both SetOperationAction is configured to be Custom? Is it related with number of results of given operation and

Hi all, I think there is a typo in TargetLowering.cpp where Names[RTLIB::SYNC_FETCH_AND_XOR_4] = "__sync_fetch_and-xor_4"; is given, and it looks like it should be "__sync_fetch_and_xor_4"; This was added here: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/TargetLowering.cpp?view=diff&r1=106320&r2=106321

Thank you Craig for explanation. Could be the same algorithm used for custom legalizing given node in LowerOperation and ReplaceNodeResults in case results and inputs of the node are illegal? Or actually such situation is impossible and for given node either LowerOperation or ReplaceNodeResults can be only called? Przemek wt., 28 sty 2020, 18:48 użytkownik Craig Topper <craig.topper at

This patch is needed to have TargetLowering::getPICJumpTableRelocBase return a GLOBAL_OFFSET_TABLE node when a jump table entry is encoded as a GPRel64BlockAddress. This should have been included in r149668, but somehow I missed it: http://article.gmane.org/gmane.comp.compilers.llvm.cvs/107188 -------------- next part -------------- An HTML attachment was scrubbed... URL:

A change has just been committed that changes the interface for TargetLowering::LowerCallTo and TargetLowering::LowerCall. Instead of passing a mess of parameters to these functions, a new structure has been created that encapsulates these parameters. The motivation is that additional fields can be added to this structure (with appropriate changes to SelectionDAGBuilder for populating the new

Hi, I'd like to add support for addrspacecast in initializers of global variables, at least for the trivial case. The trivial case is if TargetLowering::isNoopAddrSpaceCast(SrcAS, DestAS) returns true. In this case the MCExpr for the addrspacecast is the MCExpr of its first operand. It seems hard to obtain an instance of TargetLowering in AsmPrinter::lowerConstant(). Other methods in

Hi, On my target, most value types can be stored in two register classes. For example: def SReg_64 : RegisterClass<"AMDGPU", [i64], 64, (add SGPR_64, VCC, EXEC)>; def VReg_64 : RegisterClass<"AMDGPU", [i64], 64, (add VGPR_64)>; What criteria should I use to decide which register class to associate with each type using TargetLowering::addRegisterClass() ? Thanks,

Hi, I'm about to commit a change to TargetLowering::getSetCCResultType, adding an LLVMContext & argument to it ( http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130506/174067.html). Out of tree targets will need to be updated to build, but it's a simple change. You only need to add the new first argument it. - Matt Arsenault -------------- next part --------------

TargetLowering::LowerCall is already a mess, I would really prefer not to extend it any further. It's especially difficult to justify extending it without a use in the open source tree. We really should think hard about how to improve the API in two ways. Perhaps we should wrap the arguments in some struct rather than as individual ones. We should also make it easier to extend it in the