search for: getsetccresulttyp

...torType()))) 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 guarantee that TLI.getSetCCResultType() returns a valid type. From: Rotem, Nadav [mailto:nadav.rotem at intel.com] Sent: Friday, July 27, 2012 12:25 PM To: Villmow, Micah; Developers Mailing List Subject: RE: TLI.getSetCCResultType() and/or MVT broken by design? Hi Micah, I think that getSetCCResultType should only be called for le...

...wo 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 Subject: RE: TLI.getSetCCResultType() and/or MVT broken by design? 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...

I'm running into lots of problems with this call back. Mostly the problem occurs because this callback is used before types are legalized. However, the code generator does not have a 1-1 correspondence between all LLVM types and the codegen types. This leads to problems when getSetCCResultType is passed in an invalid type, but has a valid LLVM type attached to it. An example is <3 x float>. getSetCCResultType can return any type, and in the AMDIL backends case, for a <3 x float>, returns the corresponding integer version of the vector. The problem comes in code like the foll...

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

Hi, I'm working on a target which have a variable size for CC (the same size as the arguments). As a result getSetCCResultType, return a variable size. In this commit, at the line DAG.getSExtOrTrunc(SetCC, DL, SelectVT), on my target, you end up generating the Node you are replacing, and so creating a loop in the DAG, which give a whole new meaning to the A in the acronym. Subsequent code manipulating the DAG to not like...

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 GMT-07:00 Matt Arsenault <arsenm2 at gmail.com>: > > On Jul 4, 2014, at 8:18 PM, deadal nix <deadalnix at gmail.com> wrote: > > > Hi, > > > > I'm working...

...; return a 32-bit value. >> e.g. Our libcall for comparing two floats is >> >> char _eq_f32 (float a, float b); >> >> rather than >> >> long _eq_f32 (float a, float b); >> >> >> - Sanjiv >> >> > Why not use TLI.getSetCCResultType () ? > > - Sanjiv > > Duncan, Any thoughts ? Or am I missing something very obvious here? - Sanjiv

...ith intrinsics for some of our vector operations. We decided to try to solve it by representing the predicate registers as what they really are, namely i8. We changed our intrinsic and instruction definitions accordingly, changed the data type of the predicate registers to be i8, and changed getSetCCResultType() to return i8. After doing this, the compiler builds just fine but dies at runtime trying to match some target independent operations (e.g. setcc/brcond) that appear to want an i1 for the condition code. So, my question is this: is it even possible to represent our predicate registers (and...

...ome > of our vector operations.  We decided to try to solve it by representing > the predicate registers as what they really are, namely i8.  We changed > our intrinsic and instruction definitions accordingly, changed the data > type of the predicate registers to be i8, and changed > getSetCCResultType() to return i8.  After doing this, the compiler > builds just fine but dies at runtime trying to match some target > independent operations (e.g. setcc/brcond) that appear to want an i1 for > the condition code. > > So, my question is this: is it even possible to represent our predi...

...Our libcall for comparing two floats is >>> >>>   char _eq_f32 (float a, float b); >>> >>> rather than >>> >>>   long _eq_f32 (float a, float b); >>> >>> >>> - Sanjiv >>> >>> >> Why not use TLI.getSetCCResultType () ? >> >> - Sanjiv >> >> > Duncan, > Any thoughts ? > Or am I missing something very obvious here? getSetCCResultType has nothing to do with the result of a libcall; for example, on x86 it's i8 even though any libcalls like that will return an i32. You reall...

...t;> char _eq_f32 (float a, float b); > >>> > >>> rather than > >>> > >>> long _eq_f32 (float a, float b); > >>> > >>> > >>> - Sanjiv > >>> > >>> > >> Why not use TLI.getSetCCResultType () ? > >> > >> - Sanjiv > >> > >> > > Duncan, > > Any thoughts ? > > Or am I missing something very obvious here? > > getSetCCResultType has nothing to do with the result of a libcall; > for > example, on x86 it's i8 ev...

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 SetCC type for vectors!"' failed. I'm still learning LLVM, but unfortunately I don't know what this assert could be related to. I would really appreciate any input on this. I'm ru...

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 DAGTypeLegalizer::PromoteIntRes_SETCC() from inserting the truncate without blowing all other type promotion...

...ginally and wasn't what I was changing. > selectcc might not be legal, and I'm not sure why it even exists. I don't > see how it's any harder to match select + setcc vs. selectcc, and selectcc > just gives you another case to worry about. > > > > - Why calling getSetCCResultType(VT) ? VT is not the type of a > parameter of setcc, and this looks incorrect to me. > That's what it did originally, and what I fixed. It now checks > getSetCCResultType of the operand's operand's value type, the setcc's > operand -------------- next part --------------...

...vector operations.  We decided to try to solve it by representing >> the predicate registers as what they really are, namely i8.  We changed >> our intrinsic and instruction definitions accordingly, changed the data >> type of the predicate registers to be i8, and changed >> getSetCCResultType() to return i8.  After doing this, the compiler >> builds just fine but dies at runtime trying to match some target >> independent operations (e.g. setcc/brcond) that appear to want an i1 for >> the condition code. >> >> So, my question is this: is it even possible to...

...Later on, it also sees that the two operands to the xor are neither setcc, so it converts the xor to setcc again. I would be fine with this, but when it tries to find the output type of the setcc, it chooses i32 instead of i1. Again, it seems this happens from the line of code that is: SetCCVT = getSetCCResultType(SetCCVT) All that function does though is return the data type for pointers. Well, to my questions I guess. Why is this happening? Isn't it kinda silly to convert a setcc to an xor, and then convert it back to a slightly different output setcc. And how can I prevent this, or fix it, since my...

...alues, 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 didn't get Krzysztof Parzyszek e-mail in my inbox, but > thanks for the fact I can override the getSetCCResultType. Didn't even > think of that. > > -Dilan > > On Wed, Jul 19, 2017 at 7:28 PM Dilan Manatunga <manatunga at gmail.com> > wrote: > >> Hi, >> >> I am having some issues with how some of the instructions are being >> legalized. >> So this is...

...subsequent assert comes in ExpandVSELECT, which expects (for no good reason as far as I can tell) that the "mask" (really the 'selector') and the operands will be the same width, rather than trying to make them the same width (in our problem cases, the mask is an i32 produced from getSetCCResultType() and the ops are i8 or i16 - all vectors of the same length, of course.) I don't really want to fix that, as the generated XOR/AND/AND/OR sequence isn't desirable at all for our target, which has an instruction that I think does precisely VSELECT… Richard

Duncan Sands wrote: > Hi Sanjiv, I think a lot of the softening code assumes you are dealing > with float (32 bits). So it's not just a matter of changing the libcall > return type. > Yes, we are dealing with 32-bits only. But why the cmp libcalls have to return a 32-bit value. e.g. Our libcall for comparing two floats is char _eq_f32 (float a, float b); rather than long

...ealing with 32-bits only. But why the cmp libcalls have to > return a 32-bit value. > e.g. Our libcall for comparing two floats is > > char _eq_f32 (float a, float b); > > rather than > > long _eq_f32 (float a, float b); > > > - Sanjiv > Why not use TLI.getSetCCResultType () ? - Sanjiv > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >