similar to: [LLVMdev] LLVM commit 410f38e01597120b41e406ec1cea69127463f9e5

OK, so in you case, you want DAG.getSExtOrTrunc(SetCC, DL, SelectVT) to tunc the result from i64 to i32 on 64 bits targets, if I understand correctly. 2 questions: - Why not generating a selectcc node directly ? It avoid having to mess up with intermediate values. - Why calling getSetCCResultType(VT) ? VT is not the type of a parameter of setcc, and this looks incorrect to me. 2014-07-05 0:34

OK from what I understand, the DAG.getSExtOrTrunc(SetCC, DL, SelectVT) is unecessary and the SelectVT is nto the right type (as it is called with incorrect parameter). Here is a patch so it won't generate a loop. I ran make check and it doesn't look like anything is broken. 2014-07-07 11:36 GMT-07:00 Matt Arsenault <arsenm2 at gmail.com>: > > On Jul 5, 2014, at 7:14 PM,

2014-07-08 12:11 GMT-07:00 Matt Arsenault <Matthew.Arsenault at amd.com>: > On 07/07/2014 09:47 PM, deadal nix wrote: > > OK from what I understand, the DAG.getSExtOrTrunc(SetCC, DL, SelectVT) > is unecessary and the SelectVT is nto the right type (as it is called with > incorrect parameter). > > Here is a patch so it won't generate a loop. I ran make check and

On 07/08/2014 03:20 PM, Matt Arsenault wrote: > Alternatively maybe this should only be done if the setcc type is the > same as the sext result? I think we should actually do this. If you need to convert the setcc result after, you aren't really gaining anything by doing this transformation -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Mar 8, 2013, at 2:29 PM, Nadav Rotem <nrotem at apple.com<mailto:nrotem at apple.com>> wrote: Hi Richard, visitSIGN_EXTEND() in DAGCombiner.cpp generates an ISD::SELECT even if VT is a vector, which causes ExpandSELECT() to assert during legalization. I think what's required is to have visitSIGN_EXTEND generate a VSELECT if VT is a vector… ISD::SELECT should be used for

Hi Richard, > > I did… It originates from an icmp ne <2x i8>, zero initializer followed by a sext of the result 2x i1 to 2x i8. When we visit the SIGN_EXTEND, we generate the ISD::SELECT even though the selector and both operands are vectors. > It sounds like a bug in the dag combine optimization. If you send me the line number I will take a look. >> We should probably

Background: The Cell SPU does not have condition registers in the normal sense. It fits the "zero or negative one" model, preferably with an i32 register, which is what getSetCCResultType() will return. Problem: LegalizeTypes promotes i1 to i8 via an i32 setcc, i.e., the generated type legalization is: (i8:truncate (i32:setcc i32:lhs, i32:rhs, ch:cond)) How do I keep

if (N0.getOpcode() == ISD::SETCC && (LegalOperations || (!LegalOperations && VT.isPow2VectorType()))) But the comment right after it is: // sext(setcc) -> sext_in_reg(vsetcc) for vectors. // Only do this before legalize for now. if (VT.isVector() && !LegalOperations) { So, these optimizations are never safe in the general case if we can't

Hi, I am having some issues with how some of the instructions are being legalized. So this is my intial basic block. The area of concern is the last three instructions. I will pick and choose debug output to keep this small. SelectionDAG has 36 nodes: t0: ch = EntryToken t6: i32,ch = CopyFromReg t0, Register:i32 %vreg507 t2: i32,ch = CopyFromReg t0, Register:i32 %vreg17

But isn't kinda silly that we transform to xor and then we transform it back. What is the advantage in doing so? Also, since we do that method, I now have to introduce setcc patterns for i1 values, instead of being able to just use logical pattern operators like not. -Dilan On Fri, Jul 21, 2017 at 11:00 AM Dilan Manatunga <manatunga at gmail.com> wrote: > For some reason I

This post is related to the following post http://lists.llvm.org/pipermail/llvm-dev/2016-April/098823.html I'm still trying to compile a library with clang. But now I'm getting as assert in lib/CodeGen/TargetLoweringBase.cpp:1155: virtual llvm::EVT llvm::TargetLoweringBase::getSetCCResultType(llvm::LLVMContext&, llvm::EVT) const: Assertion `!VT.isVector() && "No default

Hey folks, We are having some difficulty with how we have been representing our predicate registers, and wanted some advice from the list. First, we had been representing our predicate registers as 1 bit (i1). The truth, however, is that they are 8 bits. The reason for this is that they serve as predicates for conditional execution of instructions, branch condition codes, and also as

On Tue, Feb 28, 2012 at 11:17 AM, Tony Linthicum <tlinth at codeaurora.org> wrote: > Hey folks, > > We are having some difficulty with how we have been representing our > predicate registers, and wanted some advice from the list.  First, we > had been representing our predicate registers as 1 bit (i1).  The truth, > however, is that they are 8 bits.  The reason for this is

We no longer have vsetcc, so the comment is wrong. The code looks incorrect. The fact that a vector is power-of-two does not guarantee anything about its legality. For example <128 x i64> would pass the condition in the code below, and die on most targets. From: Villmow, Micah [mailto:Micah.Villmow at amd.com] Sent: Friday, July 27, 2012 22:33 To: Rotem, Nadav; Developers Mailing List

Explicitly re-adding a node to be processed doesn't work, because the processing order is canonical. 2017-05-22 11:39 GMT-07:00 Nirav Davé <niravd at google.com>: > You can always explicitly add D to the worklist when you make the > transformation with AddToWorklist. Presuambly this was the cause for your > infinite loop. > > -Nirav > > > On Mon, May 22, 2017 at

Hi, I'm investigating an issue with the PTX backend I've come across (latest version from the trunk). Not being very familiar with Selection Dags, it's highly likely that I misunderstand some part of the process. I'd appreciate if someone can point me in the right direction. Here's the LLVM IR that is causing problems (I'm aware this code doesn't do anything

Hi Micah, I think that getSetCCResultType should only be called for legal types. Disabling it on isPow2VectorType is not the way to go because there are other illegal vector types which are pow-of-two. I suggest that you call it only after type-legalization. BTW, you can't set the LLVMTy yourself because you don't have access to the LLVMContext at that point. Nadav From:

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

I'd think i1 would be the proper and correct choice for a carry flag for the generic instruction. I expect that would also make UADDO/USUBO redundant with ADDC/SUBC (which would seem a good outcome). You'd need to make sure the right thing happened when converting from ADDC's 1-bit carry in/out to X86ISD::AD[DC]'s EFLAGS i/o. Right now the conversion can get away with assuming

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant