similar to: [LLVMdev] Typo in TargetLowering.cpp ?

Hi, I think there are a set of typos in the ATOMIC_LOAD_UMIN_I* and ATOMIC_LOAD_UMAX_I* pseudo-instructions . Specifically, def ATOMIC_LOAD_MIN_I32 : PseudoInst< (outs GPR:$dst), (ins GPR:$ptr, GPR:$val), NoItinerary, [(set GPR:$dst, (atomic_load_min_32 GPR:$ptr, GPR:$val))]>; and def ATOMIC_LOAD_UMIN_I32 : PseudoInst< (outs

--- Prevents errors like these: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-apps/shadow/files/shadow-4.1.5-stdarg.patch?view=diff&r1=text&tr1=1.1&r2=text&tr2=1.1&diff_format=s helper/utils.c | 1 + 1 file changed, 1 insertion(+) diff --git a/helper/utils.c b/helper/utils.c index 67d8ad2..c211a03 100644 --- a/helper/utils.c +++ b/helper/utils.c @@ -16,10

Thanks. Fixed with r147032. Evan On Dec 16, 2011, at 1:50 AM, George Russell wrote: > Hi, > > I think there are a set of typos in the ATOMIC_LOAD_UMIN_I* and > ATOMIC_LOAD_UMAX_I* > pseudo-instructions . > > Specifically, > > def ATOMIC_LOAD_MIN_I32 : PseudoInst< > (outs GPR:$dst), (ins GPR:$ptr, GPR:$val), NoItinerary, >

Hi Evan, The problem repeats with the i8 and i16 variants, as well. Cheers, George On 21/12/2011 04:07, Evan Cheng wrote: > Thanks. Fixed with r147032. > > Evan > > On Dec 16, 2011, at 1:50 AM, George Russell wrote: > >> Hi, >> >> I think there are a set of typos in the ATOMIC_LOAD_UMIN_I* and >> ATOMIC_LOAD_UMAX_I* >> pseudo-instructions .

Why is the SELECT statement below putting a "?" in for the username? I am using today's CVS. Jan 13 18:48:41 WARNING[7570]: res_config_odbc.c:105 realtime_odbc: SQL Execute error! [SELECT * FROM sip_buddies WHERE name = ?] Full dump: Sip read: REGISTER sip:198.88.216.85 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.2:5060;branch=z9hG4bK-ffmzndpfrao2;rport From: "Mike's Peoria

I don't know since when, but this file has been changed to remove all the trickery (aka defines) needed for MinGW-w64 (and probably everything else that as forgotten) to succesfully compile it. Attached is a patch that reintroduces the compiler checking. I would like to see this in LLVM 3.0, otherwise (by the looks of the reintroduced code) anything newer than _MSC_VER_1500 will be broken.

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

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