search for: isellowering

...0 0x3741540: ch = BasicBlock<else 0x373c230> [ID=3] 0x3741140: ch = brcond 0x37241a8, 0x3741740, 0x3741540 [ID=8] Which is invalid as setcc should always return an i1 type. I'm unsure as to whether this is coming from the -1 constant turning the setcc into an i64, or just the ISelLowering being set up incorrectly. http://llvm.org/docs/CodeGenerator.html#targetlowering does indicate that the return type of setcc operations should be specified in this class, though I'm not sure how this should be done. Any help would be appreciated, (I've read through much of the docs but...

...the ideal way of implementing the custom library calls? Providing us with a target backend having a similar functionality would also help us significantly. Say for a i64 type compare, does adding it in the RuntimeLibcalls.def enum, SelectionDAGLegalize::ConvertNodeToLibcall function, and the target ISelLowering Class solve our problem? Is it okay to modify RuntimeLibcalls.def and SelectionDAGLegalize::ConvertNodeToLibcall function? A starting point for processing lib calls other than the ISelLowering class would also help! Thank you in advance for your help! Sincerely, Miguel Inigo J. Manalac (1852) JA...

Hi All, when looking through all the existing targets, I see that each of them defines <Target>ISelLowering.{cpp,h} files. However, they define a class called "<Target>TargetLowering" (though the comments in [at least some of] those files stay the define "<Target>ISelLowering". I suspect that this class was renamed at some time (which makes sense, since I don't think...

Hello, I am following up on the issue discussed at the SVE meeting, Sander mentioned that there were some patterns missing from SVE CodeGen for floating point operations, but I was unable to identify them. He mentioned something about looking at the ISelLowering for AArch64 to identify them, so if there is any information of that regard it would be greatly appreciated so we can contribute with the missing patterns that will be required later on when fixed-width vectors are implemented. Best regards, Danilo Carvalho Grael -------------- next part ---------...

...LLVM. So, does LLVM ARM Backend assume that only "cmp" and "test" instructions can set the Status flags and not the usual arithmetic instructions. Is there any way of specifying to Backend that add can also modify status flag through "s" bit. 2. Also, when I looked at ISelLowering file, I noticed that conditions used in "icmp" instructions are converted to ARM Predicate Condition fields. Icmp has only "10" conditions, which map to corresponding "10" conditions in ARM Condition field but ARM can have fourteen conditions. If we consider the mappin...

I looked around the codebase and didn't see anything that obviously looked like the natural place to turn constant zero immediates into zero-registers (i.e. registers that always return zero when read). Right now we are expanding them in ISelLowering::LowerOperation but that seems too early. The specific issue I'm hitting is that we have a register that reads as -1 and so when we replace -1 too early with this register, the standard "not" pattern (xor x, -1) will fail to match to "not". Thanks, Sean Silva -------------...

...ifying from Mips backend. My architecture has a store instruction with direct address mode. It accepts two arguments: source register and address (immediate). This instruction is not available in Mips, but it is in Hexagon, so I copied from Hexagon the following, adapting it to my registers: - In ISelLowering.h: CONST32 and CONST32_GP - In ISelLowering.cpp: LowerGlobalAddress - In TargetObjectFile.cpp: isGlobalInSmallSection - In InstrInfo.td: def SDTmyCONST32 : SDTypeProfile<1, 1, [ SDTCisVT<0, i32>, SDTCi...

...probably, > those you don't want). See, e.g., http://reviews.llvm.org/D18802. > > Another approach could be to use the (also complex) SelectionDAG > legalization machinery to convert the operations you don't want into > "legal" ones (that'd be in <target>ISelLowering.cpp, and > Legalize*.cpp). > > > I'm pretty sure that there is a list of > > opcodes to semantics mappings. > > There isn't, because nothing LLVM does needs it, and, more > importantly, because you can't express every ISA in LLVM IR (and vice > versa). >...

Hello. Because I experience optimizations (DCE, OoO schedule) which mess the correct semantics of the list of instructions lowered in ISelLowering from the VSELECT LLVM instruction, and these bad transformations happen even before scheduling, at later I-sel subpasses, I try to fix this problem by lowering VSELECT to only one pseudo-instruction and LATER translate it to a list of instructions and use bundles and maybe also PredicateInstruc...

Hello all, I would like to restrain the compiler that I build on my local box from picking all but a particular set of opcodes. Is there a way to accomplish this in a straightforward way? I'm pretty sure that there is a list of opcodes to semantics mappings. In addition, is there a way to look at an associative mapping of LLVM IR to opcode, and/or vice versa? -------------- next part

...e. It's not taking advantage of the fact that instructions can set the condition register bits. It's a known codegen deficiency. On x86 it's generally not a *huge* issue but I have no idea what its impact is on various ARM implementations. > > > 2. Also, when I looked at ISelLowering file, I noticed that > conditions used in "icmp" instructions are converted to ARM > Predicate Condition fields. Icmp has only "10" conditions, which map > to corresponding "10" conditions in ARM Condition field but ARM can > have fourteen condition...

All, About two months ago I posted a patch that hoisted the hottest case statement from a switch statement during ISelLowering. See: http://reviews.llvm.org/D5786 Sean was rather adamant about using a Huffman tree (and I agree this is a more complete solution), so I'd like to put a patch together. That being said, I have a few questions. The current switch lowering code sorts based on case values and is lowered wit...

...le to modify this selection of "ADD" to "ADDS"( provided we somehow determine that we need ADDS here), then everything else related to ARM instruction generation has been handled in current infrastructure. Is this correct or do we need to modify other things also? 2. In file ARMISelLowering.cpp, inside function FPCCtoARMCC, condition ISD::SETO generates ARMCC::VC ( Overflow clear) condition. Thus, if we are able to appropriately generate ISD::SETO inside SDNode for overflow clear and then map it to ARMCC::VC instruction in IntCCtoARMCC, then will that be enough to generate the an inst...

...CIfType< [i16], CCPromoteToType<i32>>”, to the CallingConv.td, then “all” the 16 bits operands will be automatically promoted to 32 bits, it will be all set. but looks it is not the case. (2) Then I tried adding something like “ setOperationAction(ISD::ADD, MVT::i16, Promote)” to the IselLowering, it still failed to select the (i16 + i16).. wondering which part I missed? best Kevin

...ne i32 @main (i32 %0, i32 %1) { %tmp = add i32 %0, %1 ... } I would like to make sure %0 has some initial value (e.g. i32 0) under some circumstances. Is there any easy way to do this? I understand that %0 comes from a live-in value which is defined from outside of the function. I could, at the ISelLowering stage when seeing an ADD, replace the “%0” with a i32 constant 0, but I don’t feel like this is the right approach. Should I try to look into SUBREG_TO_REG/INSERT_REG here? Or any other thoughts? Thanks, - Cheng-Chih

...ble to know the original signature for floating point functions. In some cases, need to create calls to helper functions based on the signatures. In newer code I've written, I've actually moved this logica to an IR pass and in that case I know for sure. But this part of the code is in ISelLowering code and I rely on getting the proper signature information. I'm looking at llvm now to see how this is occurring but maybe someone just knows. Tia. Reed

> On Mon, Dec 15, 2014 at 9:57 AM, Chad Rosier <mcrosier at codeaurora.org> > wrote: >> All, >> About two months ago I posted a patch that hoisted the hottest case >> statement from a switch statement during ISelLowering. >> >> See: http://reviews.llvm.org/D5786 >> >> Sean was rather adamant about using a Huffman tree (and I agree this is >> a >> more complete solution), so I'd like to put a patch together. > > I think this sounds really cool! > >> That being &...

...al type. The idea is that this returned value shall be eliminated when the Intrinsic node is lowered to a target node. I realize that this is a rather late stage, since (at least) SelectionDAGLowering::visitTargetIntrinsic() requires legal types, and type legalization in general is also done before ISelLowering. The background is that the intrinsic returns a boolean value which is evaluated by a branch instruction of a (special) loop. The branch targets of this kind of loop are actually controlled and generated by hardware. So in the end the intrinsic should become the branch instruction and the origina...

...n't be a very generic fix. The right fix is to add a pass to optimize away the cmp instruction by *folding* it in the preceding add when it's legal. Ideally this will be a target independent pass that x86 and other targets can take advantage of as well. > > > 2. In file ARMISelLowering.cpp, inside function FPCCtoARMCC, > condition ISD::SETO generates ARMCC::VC ( Overflow clear) condition. > Thus, if we are able to appropriately generate ISD::SETO inside > SDNode for overflow clear and then map it to ARMCC::VC instruction > in IntCCtoARMCC, then will that be en...

On Dec 1, 2008, at 8:53 AM, Matthijs Kooijman wrote: > Hi All, > > when looking through all the existing targets, I see that each of > them defines > <Target>ISelLowering.{cpp,h} files. However, they define a class > called > "<Target>TargetLowering" (though the comments in [at least some of] > those > files stay the define "<Target>ISelLowering". > > I suspect that this class was renamed at some time (which make...