similar to: Question about TargetLowering::SimplifyDemandedBits with AND

The code below is triggering some weird behavior that's different from how gcc treats this inline asm. Clang keeps the original type of "loc" as "bool", which generates an "i1 true" after inlining. So far so good. However, during ISEL, the "true" is converted to a signed integer. So when it's evaluated, the result is this: .quad

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

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

On Jan 6, 2009, at 11:37 PM, Scott Michel wrote: > Chris: > > I was trying to avoid using the custom instruction emitter method. > Not as if I didn't look before I asked the question to see if there > was an easier way. Then no, there is no other way. -Chris

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

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, 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,

The thing I wanted for mips 16 for large literals does not seem to exist right now. They have MipsTargetLowering::isFPImmLegal(const APFloat &Imm, EVT VT) but not the same thing for integer literals. For Mips16, to materialize a 32 bit literal using instructions is expensive, both in terms of the number of registers and the number of instructions. You always want to just do a load of

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 --------------

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

> > 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

Chris: It occurred to me this morning that maybe the general solution to this particular type of problem is a custom/target-dependent DAG inserter pass, analogous to target lowering and DAG legalization. I'm not sure if this pass happens before or after legalization. Worth considering? I suppose the best way to discuss this is to just write the code. However, some preliminary

On Jan 6, 2009, at 5:53 PM, Scott Michel wrote: > It's yet another CellSPU thing: integer division is a long code > sequence we have to insert that has branches within it (test for 0 > divisor, etc.) Can't really emit the sequence of instructions via > tblgen (can't have labels or BBs). The other alternative is a custom > instruction emitter. > > Life could be

Hi! I am trying to implement va_arg() on ppc32. Everything went smooth, except implementing va_arg() of 64bit int. Since i64 is not a legal type on ppc32 DAGTypeLegalizer::ExpandRes_VAARG() splits the va_arg(i64) into two i32 va_args. The problem with ppc32 va_arg is that it needs special "alignment" of its gpr pointer when the argument is i64. Ie. I need to know if I am lowering

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

Chris: I was trying to avoid using the custom instruction emitter method. Not as if I didn't look before I asked the question to see if there was an easier way. -scooter On Tue, Jan 6, 2009 at 10:07 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jan 6, 2009, at 5:53 PM, Scott Michel wrote: > > > It's yet another CellSPU thing: integer division is a long

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

It's yet another CellSPU thing: integer division is a long code sequence we have to insert that has branches within it (test for 0 divisor, etc.) Can't really emit the sequence of instructions via tblgen (can't have labels or BBs). The other alternative is a custom instruction emitter. Life could be easier if I could insert BRCONDs and other branches from within

You are right: select in SDAG has to be poison-blocking as well, otherwise the current lowering from IR's select to SDAG's select would be wrong. Which makes the select->or transformation incorrect at SDAG level as well. I guess until recently people believed that poison in SDAG wasn't much of a problem (myself included). I was convinced otherwise with the test cases that